perm filename MSG.MSG[STR,LSP]9 blob
sn#824688 filedate 1986-09-19 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00139 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00018 00002
C00019 00003 ∂17-Mar-86 2120 RPG Welcome
C00021 00004 ∂21-Mar-86 1842 FAHLMAN@C.CS.CMU.EDU Getting things rolling
C00029 00005 ∂21-Mar-86 2038 FAHLMAN@C.CS.CMU.EDU Documenting our decisions
C00038 00006 ∂25-Mar-86 0313 gls@THINK-AQUINAS.ARPA Documenting our decisions
C00045 00007 ∂25-Mar-86 0320 FAHLMAN@C.CS.CMU.EDU Documenting our decisions
C00047 00008 ∂25-Mar-86 0321 FAHLMAN@C.CS.CMU.EDU [yuasa: forwarded]
C00055 00009 ∂25-Mar-86 0333 FAHLMAN@C.CS.CMU.EDU Documenting our decisions
C00059 00010 ∂25-Mar-86 0338 OHLANDER@USC-ISIB.ARPA Re: Documenting our decisions
C00061 00011 ∂25-Mar-86 1005 gls@THINK-AQUINAS.ARPA Documenting our decisions
C00064 00012 ∂25-Mar-86 2149 FAHLMAN@C.CS.CMU.EDU Documenting our decisions
C00068 00013 ∂26-Mar-86 0833 FAHLMAN@C.CS.CMU.EDU FYI
C00075 00014 ∂26-Mar-86 1009 RPG Document
C00077 00015 ∂26-Mar-86 1427 FAHLMAN@C.CS.CMU.EDU [OHLANDER: Documenting our decisions]
C00080 00016 ∂26-Mar-86 1500 Moon@ALLEGHENY.SCRC.Symbolics.COM Documenting our decisions
C00083 00017 ∂26-Mar-86 2026 FAHLMAN@C.CS.CMU.EDU Documenting our decisions
C00089 00018 ∂27-Mar-86 1946 DLW@SCRC-STONY-BROOK.ARPA Documenting our decisions
C00094 00019 ∂27-Mar-86 1955 DLW@SCRC-STONY-BROOK.ARPA [yuasa: forwarded]
C00098 00020 ∂27-Mar-86 2220 FAHLMAN@C.CS.CMU.EDU [yuasa: forwarded]
C00101 00021 ∂28-Mar-86 0808 GRISS%HP-HULK@hplabs.ARPA Ida
C00103 00022 ∂28-Mar-86 0948 RPG New Members
C00104 00023 ∂28-Mar-86 1008 OHLANDER@USC-ISIB.ARPA Re: [yuasa: forwarded]
C00106 00024 ∂28-Mar-86 1255 FAHLMAN@C.CS.CMU.EDU New Members
C00109 00025 ∂28-Mar-86 2041 DLW@SCRC-STONY-BROOK.ARPA Ida
C00112 00026 ∂28-Mar-86 2157 JMC Japanese representative
C00113 00027 ∂29-Mar-86 0806 FAHLMAN@C.CS.CMU.EDU Japanese representative
C00115 00028 ∂29-Mar-86 0809 FAHLMAN@C.CS.CMU.EDU Random note
C00117 00029 ∂29-Mar-86 0828 DLW@SCRC-STONY-BROOK.ARPA New Members
C00119 00030 ∂01-Apr-86 0735 FAHLMAN@C.CS.CMU.EDU Docmenting the decisions
C00125 00031 ∂01-Apr-86 1358 ALAN@MC.LCS.MIT.EDU Docmenting the decisions
C00126 00032 ∂03-Apr-86 1412 MATHIS@USC-ISIF.ARPA Documenting...
C00133 00033 ∂03-Apr-86 1727 OHLANDER@USC-ISIB.ARPA Re: Documenting...
C00135 00034 ∂04-Apr-86 0820 gls@THINK-AQUINAS.ARPA Documenting...
C00141 00035 ∂10-Apr-86 2008 FAHLMAN@C.CS.CMU.EDU Documenting...
C00144 00036 ∂18-Apr-86 1922 squires@ipto.ARPA Japanese representative
C00148 00037 ∂18-Apr-86 1925 squires@ipto.ARPA Re: Suggested Japanese representative for Common Lisp
C00150 00038 ∂19-Apr-86 1404 FAHLMAN@C.CS.CMU.EDU Japanese representative
C00156 00039 ∂20-Apr-86 0838 GRISS%HP-HULK@hplabs.ARPA Japanese Representative
C00157 00040 ∂20-Apr-86 0900 FAHLMAN@C.CS.CMU.EDU Japanese Representative
C00160 00041 ∂20-Apr-86 1001 RPG Chairman
C00161 00042 ∂20-Apr-86 1231 GRISS%HP-HULK@hplabs.ARPA Re: Chairman
C00163 00043 ∂20-Apr-86 1256 GRISS%HP-HULK@hplabs.ARPA Japanese Representative
C00164 00044 ∂21-Apr-86 0844 MATHIS@USC-ISIF.ARPA message from/re Ida
C00171 00045 ∂21-Apr-86 0908 Bobrow.pa@Xerox.COM Re: Chairman
C00172 00046 ∂21-Apr-86 1025 MATHIS@USC-ISIF.ARPA Re: Chairman
C00175 00047 ∂21-Apr-86 1102 MATHIS@USC-ISIF.ARPA BALLOT - Mathis Chairman?
C00177 00048 ∂21-Apr-86 1108 RPG Should Mathis ...
C00178 00049 ∂21-Apr-86 1151 FAHLMAN@C.CS.CMU.EDU BALLOT - Mathis Chairman?
C00180 00050 ∂21-Apr-86 1754 OHLANDER@USC-ISIB.ARPA Mathis as Chairman
C00181 00051 ∂21-Apr-86 1913 Bobrow.pa@Xerox.COM Re: BALLOT - Mathis Chairman?
C00182 00052 ∂22-Apr-86 0540 MATHIS@USC-ISIF.ARPA EuLisp
C00184 00053 ∂22-Apr-86 0732 DLW@SCRC-STONY-BROOK.ARPA Lisp conference
C00188 00054 ∂22-Apr-86 0745 FAHLMAN@C.CS.CMU.EDU Lisp conference
C00191 00055 ∂22-Apr-86 0841 FAHLMAN@C.CS.CMU.EDU EuLisp
C00198 00056 ∂22-Apr-86 1335 Moon@SCRC-STONY-BROOK.ARPA EuLisp
C00200 00057 ∂22-Apr-86 2134 FAHLMAN@C.CS.CMU.EDU Specification Document
C00209 00058 ∂23-Apr-86 0924 OHLANDER@USC-ISIB.ARPA Specification Document
C00211 00059 ∂23-Apr-86 1451 Moon@SCRC-STONY-BROOK.ARPA Specification Document
C00213 00060 ∂25-Apr-86 1024 gls@THINK-AQUINAS.ARPA Re: Chairman
C00215 00061 ∂25-Apr-86 1028 gls@THINK-AQUINAS.ARPA BALLOT - Mathis Chairman?
C00217 00062 ∂25-Apr-86 1038 gls@THINK-AQUINAS.ARPA EuLisp
C00219 00063 ∂25-Apr-86 1315 FAHLMAN@C.CS.CMU.EDU Chairman
C00221 00064 ∂03-May-86 1529 squires@ipto.ARPA Japanese representative
C00225 00065 ∂03-May-86 1903 FAHLMAN@C.CS.CMU.EDU Japanese representative and other topics
C00230 00066 ∂06-May-86 1052 MATHIS@USC-ISIF.ARPA Lisp Standardization
C00232 00067 ∂06-May-86 1151 MATHIS@USC-ISIF.ARPA X3J13 Hull Pounding
C00237 00068 ∂07-May-86 0710 FAHLMAN@C.CS.CMU.EDU Addition to mailing list
C00239 00069 ∂07-May-86 1200 OHLANDER@USC-ISIB.ARPA Re: Addition to mailing list
C00240 00070 ∂08-May-86 2338 FAHLMAN@C.CS.CMU.EDU Copyrights
C00246 00071 ∂09-May-86 1130 OHLANDER@USC-ISIB.ARPA Re: Copyrights
C00248 00072 ∂09-May-86 1917 FAHLMAN@C.CS.CMU.EDU Copyrights
C00251 00073 ∂13-May-86 0143 OHLANDER@USC-ISIB.ARPA Re: Copyrights
C00254 00074 ∂13-May-86 0814 FAHLMAN@C.CS.CMU.EDU Copyrights
C00258 00075 ∂13-May-86 1109 FAHLMAN@C.CS.CMU.EDU Addition to mailing list
C00260 00076 ∂13-May-86 1439 MATHIS@USC-ISIF.ARPA copyrights
C00265 00077 ∂13-May-86 1742 FAHLMAN@C.CS.CMU.EDU copyrights
C00269 00078 ∂13-May-86 2220 JMC copyright holder
C00270 00079 ∂14-May-86 0621 FAHLMAN@C.CS.CMU.EDU copyright holder
C00272 00080 ∂14-May-86 0742 MATHIS@USC-ISIF.ARPA copyright holder
C00275 00081 ∂14-May-86 0923 RPG Gentlemen,
C00277 00082 ∂14-May-86 1029 DLW@SAPSUCKER.SCRC.Symbolics.COM Gentlemen,
C00279 00083 ∂15-May-86 1931 MATHIS@USC-ISIF.ARPA iso work on Lisp
C00291 00084 ∂15-May-86 2000 RPG
C00295 00085 ∂15-May-86 2057 FAHLMAN@C.CS.CMU.EDU iso work on Lisp
C00300 00086 ∂16-May-86 1507 MATHIS@USC-ISIF.ARPA Re: iso work on Lisp
C00302 00087 ∂16-May-86 1810 Bobrow.pa@Xerox.COM Re: iso work on Lisp
C00304 00088 ∂16-May-86 1916 FAHLMAN@C.CS.CMU.EDU iso work on Lisp
C00312 00089 ∂16-May-86 2139 RPG ISO Lisp
C00314 00090 ∂17-May-86 0741 FAHLMAN@C.CS.CMU.EDU ISO Lisp
C00317 00091 ∂27-May-86 0605 FAHLMAN@C.CS.CMU.EDU [franz!fimass!jkf: Where we stand ]
C00321 00092 ∂27-May-86 0620 FAHLMAN@C.CS.CMU.EDU Where we stand
C00326 00093 ∂27-May-86 1154 RPG Mark Your Calendars
C00328 00094 ∂27-May-86 1234 Moon@SAPSUCKER.SCRC.Symbolics.COM Where we stand
C00331 00095 ∂27-May-86 1247 FAHLMAN@C.CS.CMU.EDU Where we stand
C00334 00096 ∂27-May-86 1352 ALAN@AI.AI.MIT.EDU Where we stand
C00338 00097 ∂27-May-86 1454 DLW@SCRC-QUABBIN.ARPA Format of manual
C00342 00098 ∂27-May-86 1518 FAHLMAN@C.CS.CMU.EDU Where we stand
C00345 00099 ∂27-May-86 1545 Moon@SAPSUCKER.SCRC.Symbolics.COM Where we stand
C00350 00100 ∂27-May-86 1658 JAR@MX.LCS.MIT.EDU text
C00351 00101 ∂27-May-86 2123 FAHLMAN@C.CS.CMU.EDU Where we stand
C00356 00102 ∂30-May-86 0745 FAHLMAN@C.CS.CMU.EDU Foreigners
C00359 00103 ∂30-May-86 1257 MATHIS@USC-ISIF.ARPA Foreigners
C00362 00104 ∂30-May-86 1318 Moon@SCRC-QUABBIN.ARPA Foreigners
C00364 00105 ∂31-May-86 1927 FAHLMAN@C.CS.CMU.EDU Proposed message
C00370 00106 ∂01-Jun-86 1507 Bobrow.pa@Xerox.COM Re: Proposed message
C00372 00107 ∂01-Jun-86 1522 FAHLMAN@C.CS.CMU.EDU Proposed message
C00374 00108 ∂02-Jun-86 1240 OHLANDER@USC-ISIB.ARPA Re: Proposed message
C00375 00109 ∂03-Jun-86 1151 RPG Japan
C00376 00110 ∂03-Jun-86 1341 FAHLMAN@C.CS.CMU.EDU Japan
C00378 00111 ∂04-Jun-86 1224 RPG Japan
C00380 00112 ∂04-Jun-86 1502 FAHLMAN@C.CS.CMU.EDU Japan
C00382 00113 ∂05-Jun-86 1522 RPG Japanese
C00385 00114 ∂10-Jun-86 0656 FAHLMAN@C.CS.CMU.EDU Plans for Lisp Conference
C00387 00115 ∂10-Jun-86 0656 MATHIS@USC-ISIF.ARPA EuLisp meeting in Bath -- Private Message
C00394 00116 ∂10-Jun-86 0742 @GUIDO.THINK.COM:gls@AQUINAS.THINK.COM Mailing address
C00395 00117 ∂10-Jun-86 0943 Bobrow.pa@Xerox.COM Re: Plans for Lisp Conference
C00396 00118 ∂10-Jun-86 0943 Bobrow.pa@Xerox.COM Re: EuLisp meeting in Bath -- Private Message
C00398 00119 ∂10-Jun-86 1229 DLW@ELEPHANT-BUTTE.SCRC.Symbolics.COM Plans for Lisp Conference
C00400 00120 ∂10-Jun-86 1256 FAHLMAN@C.CS.CMU.EDU EuLisp meeting in Bath -- Private Message
C00405 00121 ∂10-Jun-86 1353 ALAN@AI.AI.MIT.EDU EuLisp meeting in Bath -- Private Message
C00407 00122 ∂10-Jun-86 1907 FAHLMAN@C.CS.CMU.EDU Plans for Lisp Conference
C00409 00123 ∂11-Jun-86 1015 DLW@QUABBIN.SCRC.Symbolics.COM Plans for Lisp Conference
C00411 00124 ∂11-Jun-86 1141 FAHLMAN@C.CS.CMU.EDU Plans for Lisp Conference
C00413 00125 ∂11-Jun-86 1409 MATHIS@USC-ISIF.ARPA Plans for Lisp Conference
C00416 00126 ∂11-Jun-86 1410 MATHIS@USC-ISIF.ARPA EuLisp
C00419 00127 ∂11-Jun-86 1410 MATHIS@USC-ISIF.ARPA Japanese and European participation
C00422 00128 ∂11-Jun-86 1449 FAHLMAN@C.CS.CMU.EDU EuLisp
C00426 00129 ∂11-Jun-86 1551 OHLANDER@USC-ISIB.ARPA Re: Japanese and European participation
C00427 00130 ∂12-Jun-86 1302 FAHLMAN@C.CS.CMU.EDU Lisp Conference
C00429 00131 ∂12-Jun-86 1515 DLW@ELEPHANT-BUTTE.SCRC.Symbolics.COM EuLisp
C00431 00132 ∂12-Jun-86 1651 FAHLMAN@C.CS.CMU.EDU EuLisp
C00434 00133 ∂12-Jun-86 2234 FAHLMAN@C.CS.CMU.EDU [a37078%ccut.u-tokyo.junet%utokyo-relay.csnet: Common Lisp Meeting]
C00438 00134 ∂12-Jun-86 2236 FAHLMAN@C.CS.CMU.EDU [Fahlman: Common Lisp Meeting]
C00445 00135 ∂13-Jun-86 1007 RPG Use of Lucid Manual
C00447 00136 ∂13-Jun-86 1121 FAHLMAN@C.CS.CMU.EDU Use of Lucid Manual
C00451 00137 ∂13-Jun-86 2149 FAHLMAN@C.CS.CMU.EDU [a37078%ccut.u-tokyo.junet%utokyo-relay.csnet: Lisp standardization]
C00465 00138 ∂14-Jun-86 0655 MATHIS@USC-ISIF.ARPA EuLisp and Boston
C00468 00139 ∂14-Jun-86 1250 FAHLMAN@C.CS.CMU.EDU Standards
C00474 ENDMK
C⊗;
∂17-Mar-86 2120 RPG Welcome
To: cl-steering@SU-AI.ARPA
...to the world of international standarization. This mailing list
is the forum for private discussions regarding the strategic aspects
of the standardization effort. The contents of the messages transmitted
on this list are archived in a private, non-accessible file at SAIL.
If you choose to also archive these messages, please guard their
privacy.
The members of this list are:
rpg,
gls%Think.COM
jmc
squires@isi
Mathis@isif
ohlander@isie
fahlman@cmuc
bobrow.pa@xerox
CL-Steering-from-SU-AI@Stony-Brook.SCRC.Symbolics.COM
(= Moon and Weinreb)
bawden@mc
rees@mc
griss@hplabs
which includes the members of the technical committee as well as those
of the steering committee. The steering committee members are:
rpg,
gls%Think.COM
jmc
squires@isi
Mathis@isif
ohlander@isie
-rpg-
∂21-Mar-86 1842 FAHLMAN@C.CS.CMU.EDU Getting things rolling
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 21 Mar 86 18:38:46 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 21 Mar 86 21:40:07-EST
Date: Fri, 21 Mar 1986 21:40 EST
Message-ID: <FAHLMAN.12192608724.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-steering@SU-AI.ARPA
Subject: Getting things rolling
I'm sending this to the steering committee because that mailing list has
the technical people on it as well. And these issues of how to get
started involve all of us.
Here are some things that we need to do, in more or less the order in
which I think we need to deal with them. The list is probably not
complete, so feel free to propose additions to it. Entires are marked
with S (steering), T (technical), S&T (both) and S,T (each committee
separately).
Get the two committees organized. Probably we don't need much
organization, but some sort of chairman or moderator is needed for each
-- someone who will feel responsible for goosing the agenda along. (S,T)
Make a list of formal things that the steering committee needs to do as
part of the ANSI and ISO formalities. Is some sort of a kick-off
meeting necessary? (S)
Conduct a poll on the Common Lisp mailing list (and maybe by other
channels) to identify what companies have people participating in
this process, even if they are content merely to observe. Prepare
a list of such participating companies, along with the name and address
of a contact person at each. This will be used for formal X3J13
notifications, etc. It will also make it clear to everyone that many
companies are participants in this process, even if they don't have
someone on the Technical committee. (S)
Determine if there are any companies (or other implementation groups)
that need arpanet access but don't have it. Try to get them accounts
somewhere. (S)
Try to establish reliable netmail contact with Japan. Once this is in
place, select a Japanese member for the technical committee. (Masayuki
Ida was discussed earlier, but we couldn't get mail to him, though mail
from him has reached me.) (S)
Send an embassy to the Eulisp people and see if they have any interest
at all in participating in this process, given our unreasonable desire
to standardize something like the current Common Lisp and not start
over as they are doing. If they want to participate, invite one or more
European members to join the committee. Netmail seems not to be a
problem. (S)
Decide on how we are going to run the technical decision-making process,
how we are going to record and communicate the results, and what sort of
form the standard document will take. (S&T). I'll describe some
thoughts I have on this issue in a later message.
Decide what major areas we are going to try to fix and/or extend in this
first version of the standard. Make for ourselves some guidelines on
how deeply we want to change things. Set ourselves a realistic schedule
for completing the first spec. (T)
Provide some guidance to the ISI folks about what services are most
needed, and what their priorities should be. (S&T)
Create an inventory of issues that have been raised. Guy made a start
at this, but it needs to be kept up to date. Divide these issues into
three classes: issues where we think there is (or could easily be)
agreement on the right solution, isolated issues that are controversial,
and issues that are all tangled together in rotten areas of the current
spec (e.g. that part about what the compiler does). (T)
For the issues where there is or could be agreement, confirm this on the
mailing list and then record the decisions so that they don't unravel
again. (T)
Debate the isolated but controversial issues in public, then make the
decisions and record them. (T)
For areas where many interrelated things need work, choose someone in
each case to put together a comprehensive proposal. Then debate the
result and nail it down. (T)
As coherent proposals for extensions appear (error, objects, whatever),
run these through the process. If there are areas where progress is
needed but no proposals exist, find someone willing to take a crack at
it. (T)
Make a final pass over the completed specification document (T) and try
to get it through ISO and ANSI (S).
Get to work on Common Lisp 2001. (Whoever survives.)
-- Scott
∂21-Mar-86 2038 FAHLMAN@C.CS.CMU.EDU Documenting our decisions
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 21 Mar 86 20:38:46 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 21 Mar 86 23:40:10-EST
Date: Fri, 21 Mar 1986 23:40 EST
Message-ID: <FAHLMAN.12192630575.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-steering@SU-AI.ARPA
Cc: fahlman@C.CS.CMU.EDU
Subject: Documenting our decisions
It seems to me that we want to focus on the production of a coherent,
complete document for ANSI Common Lisp (maybe later to be ISO Common
Lisp). We can't really expect the community to rally around the
existing Digital Press book plus a long list of corrections and a couple
of new chapters. Nor are we likely to find as many of the problems and
inconsistencies if we just handle each problem as an isolated issue.
Our most productive periods in developing this language were when we
were trying to hammer out large sections of the book to meet a deadline.
I don't think that a new edition of the Steele book will do the job.
Digital Press has been reasonably cooperative so far, but I doubt that
they will give up their copyright, and we just cannot produce a document
for the Common Lisp standard that says "Copyright Digital Press" on it.
If that book were in the public domain, we could use its actual text as
a starting point, but I don't see this happening. So it looks like we
have to develop a new document. Of course, the Common Lisp it describes
will be very similar to the Common Lisp described in Steele.
Ideally, there should be two documents, both kept online in some form
that most people can easily FTP and print (TeX?), and both kept up to
date as each decision is made. One of these documents would be the
manual documenting the proposed standard; the other would be a list of
all the deliberate incompatible changes that we have made to the
language as described in the original silver book. When we're done, the
former is our report to ANSI; the latter is a guide for all the
companies that need to update their implementations and all the users
who need to fix things in their code. The standard document needs to be
as clear and unambiguous as we can make it; it does NOT necessarily need
to be organized a a tutorial or as a convenient manual for the working
programmer, nor does it need to be subtly witty. There will presumably
be a lively market for other Common Lisp books, including the
second edition of Steele, that will fill those needs, but the new
document should become the definitive language standard.
These documents should either be public-domain or they should be
copyrighted by someone not associated with a manufacturer. If
copyrighted, there should be explicit blanket permission for anyone to
reproduce the document without charge, as long as the text is reproduced
in its entirety and any additions to the text are clearly marked as
such. [Question: is a public-domain document acceptable to ANSI and
ISO, or do they require the ability to copyright the thing for
themselves? After being burned once, I'm not too keen on working on
this thing and yielding up the copyright to ANYONE.]
Several times in the last few months I have come close to volunteering
to write a new, public-domain manual meeting the above conditions and to
keep it online here at CMU. This impulse arose out of frustration at
seeing issues be almost settled and then unravel again. Each time I've
thought about this, I've come to my senses. Writing a new manual from
scratch is more work than I am prepared to do in the next year. But
Gabriel tells me that Lucid has written a new manual, equivalent in
content but not in form to the Steele book, and therefore free of the
Digital Press copyright. He also says that Lucid might be willing to
put the sources for this document in the public domain to serve as a
starting point for the new specification.
I haven't seen this new manual yet, but if it's in good shape and if we
can indeed arrange to use it without awkward restrictions, I will
probably volunteer to hammer it into a spec and to keep it up to date
(with a little help from my friends at CMU and, I hope, from all of
you). It would be kept online and freely FTP'able at CMU. We will not
get into the hardcopy business, but maybe ISI can do that, charging
enough for copies to recoup the costs or maybe some company will decide
to crank these out quickly and cheaply.
The model would be that I get this into some initial kind of shape while
the rest of you debate the issues currently on the table. Maybe some of
the rest of you can work on particular sections. Once the document is
presentable and in line with current truth, we make a few passes through
it, chapter by chapter, debating and fixing problems and ambiguities as
we find them. Once we're happy, we ship it up to X3J13.
If anyone has a different model of how to do this, please speak up. If
there's anyone else out there who would like to do this, I'd be happy to
step aside or would be willing to help carry some part of the load. But
please don't volunteer unless you're really serious about doing this.
If we end up with a big backlog of changes to go in, things rot quickly.
Please note: I said I MIGHT volunteer for this, and that sentence had a
couple of "if's" in it.
-- Scott
∂25-Mar-86 0313 gls@THINK-AQUINAS.ARPA Documenting our decisions
Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 25 Mar 86 03:12:57 PST
Received: from wenceslas by GODOT.THINK.COM via CHAOS; Mon, 24 Mar 86 14:35:16 est
Date: Mon, 24 Mar 86 14:37 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Documenting our decisions
To: Fahlman@C.CS.CMU.EDU, cl-steering@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: <FAHLMAN.12192630575.BABYL@C.CS.CMU.EDU>
Message-Id: <860324143710.8.GLS@THINK-WENCESLAS.ARPA>
Date: Fri, 21 Mar 1986 23:40 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
...
I don't think that a new edition of the Steele book will do the job.
Digital Press has been reasonably cooperative so far, but I doubt that
they will give up their copyright, and we just cannot produce a document
for the Common Lisp standard that says "Copyright Digital Press" on it.
If that book were in the public domain, we could use its actual text as
a starting point, but I don't see this happening. So it looks like we
have to develop a new document. Of course, the Common Lisp it describes
will be very similar to the Common Lisp described in Steele.
...
The standard document needs to be
as clear and unambiguous as we can make it; it does NOT necessarily need
to be organized a a tutorial or as a convenient manual for the working
programmer, nor does it need to be subtly witty. There will presumably
be a lively market for other Common Lisp books, including the
second edition of Steele, that will fill those needs, but the new
document should become the definitive language standard.
It seems to me that there are two issues that are somewhat orthogonal:
(a) Can the ANSI effort begin with some form of the Digital press book,
or must a new document begin from scratch?
(b) Should we plan to bring out an interim edition to tide us over to the
point where something officially ANSI comes out (even in draft form)?
If the answer to (b) is yes, then a subissue is whether it should be a
second edition with Digital Press or published through some other mechanism,
such as agreeing that the Lucid document is the right thing from now on.
If the answer to (a) is no, then I would be leery of having a "competing"
new edition out of Digital press coming out at roughly the same time as the
ANSI standard, because that would only create confusion as to which is the
"real" standard, and I would rather avoid such confusion. Better to let the
Digital press book die a natural death and put my efforts into the ANSI
version.(*)
On the other hand, I worked pretty hard on the book to get a lot of subtle
things right. It is certainly not deathless prose, but it has been polished
a lot, and it would be a pity for the ANSI committee not to be able to take
advantage of that. Then again, maybe it would be a good exercise to chuck
the whole thing and start over and really get it right; more work, but
potentially bigger payoff in accuracy and clarity at the end. There is also
the possibility that the Lucid document (which I have not yet seen) is
exactly the right thing. I would be happy if it were so.
--Guy
(*) I decided to dig up my contract with Digital Press and scan it for
loopholes and traps, and found this clause, a potential pitfall for the
"natural death" theory: "The Author agrees to revise the Work for
subsequent editions if the Publisher considers it in the best interests of
the Work. [I have no idea how a Work can have "interests". --GLS] ...
Should the Author be unable or unwilling to provide such a revision... the
Publisher may have the revised edition prepared... and may display in the
revised Work and in advertising, the name of the person, or persons, who
prepared said revisions." What do I make of this? Barf.
∂25-Mar-86 0320 FAHLMAN@C.CS.CMU.EDU Documenting our decisions
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 25 Mar 86 03:20:44 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 25 Mar 86 05:39:04-EST
Date: Tue, 25 Mar 1986 01:31 EST
Message-ID: <FAHLMAN.12193437323.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: OHLANDER@USC-ISIB.ARPA
Cc: cl-steering@SU-AI.ARPA
Subject: Documenting our decisions
In-reply-to: Msg of 24 Mar 1986 15:26-EST from OHLANDER at USC-ISIB.ARPA
Ron,
Thanks for your offer of help on the standards document. If we go for
this way of documenting our decisions, ISI will probably turn out to be
the right organization to do the distribution.
On the copyright issue, it seems a lot of work to set up some sort of
"Common Lisp Users Group" corportion just to hold onto the copyright.
We can do something like this if we have to, but unless there's some
clear need for a copyright it would be easier to just produce a
public-domain document that we can all use freely.
-- Scott
∂25-Mar-86 0321 FAHLMAN@C.CS.CMU.EDU [yuasa: forwarded]
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 25 Mar 86 03:17:53 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 25 Mar 86 05:36:21-EST
Date: Sun, 23 Mar 1986 23:12 EST
Message-ID: <FAHLMAN.12193149846.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-steering@SU-AI.ARPA
Subject: [yuasa: forwarded]
Our original discussions of who should be on the technical and steering
committees took place on a smaller mailing list, but as we begin to
consider adding foreign members to these committees, I think that the
full steering and technical committees ought to be involved.
Unlike the situation in Europe, Common Lisp seems to be enthusiastically
accepted in Japan as the future standard for Lisp work. Of course,
there's also great interest in Prolog, but a lot of the companies are
quietly working on Lisp, leaving Prolog to ICOT. Anyway, it has been
our intention to add a Japanese member to the technical committee as
soon as possible.
Unfortunately, while the Japanese have occasionally sent netmail to me,
I seem to be unable to answer, and I gather that others in the U.S. have
been no more successful. The ability to stay in touch with the rest of
us by netmail and to read the Common Lisp mailing list is critical for
any prospective member of the technical committee. Have any of you had
success in sending mail over there? The message included below took
three days to reach me, and I have no idea if my attempt to reply will
work.
In our earlier discussions, the leading Japanese candidate for the
technical committee was Dr. Masayuki Ida, an assistant professor at
Aoyama Gakuin University. He is the one who translated the Common Lisp
manual into Japanese, and seems to be very active in setting up
communication among the Japanese Common Lisp community. Of course, we
want to consult with as many of the Japanese as possible before choosing
someone.
Mr. Yuasa and Mr. Hagiya of Kyoto University were also discussed. They
are technically very proficient, having implemented Kyoto Common Lisp
from scratch, with no direct help from the U.S. However, the feeling
was that they are perhaps too junior -- I think that they are the
equivalent of Research Associates in the U.S., and neither yet has his
Ph.D. The Japanese are very status conscious, so selecting a junior
person as the Japanese representative might be awkward.
Anyway, I just received the following message from Yuasa, and replied
with a test message that may or may not get through. I'll let you know
if I am able to establish contact (which would probably indicate that we
can reach Ida and some others as well). If my message doesn't make it
after a reasonable time, I'll send Yuasa some snailmail explaining that
we want to cooperate closely with them, but need reliable netmail first.
In any event, Yuasa and Hagiya should be added to the official X3J13
physical mailing list.
-- Scott
---------------------------------------------------------------------------
Date: Thu, 20 Mar 86 20:56:40+0900
From: yuasa at kurims.kurims.kyoto-u.junet
To: fahlman at cmu-cs-c.ARPA
Dear Prof. Fahlman,
Someone passed me your EMAIL on the Subject "Committee Membership for
ANSI/ISO" addressed to common-lisp@su-ai.arpa.
I am very much interested in joining the X3 Committees.
I strongly believe that we (Masami Hagiya and I) can contribute to the
standardization efforts of the US Common Lisp community.
As you may have already heard, our Common Lisp system KCL is running at more
than 150 sites in Japan on many different machines, including VAX, SUN,
Apollo Domain, and AT&T 3B2. In a sense, KCL itself is becoming the standard
in Japan. Many comments are coming to us about the language specification of
Common Lisp, and we ourselves have already got enough experiences with Common
Lisp. Indeed, half of the software produced in our institute is written in
Common Lisp now a days. We will publish an introduction book on Common Lisp
in this spring (in Japanese first, then hopefully translated into English).
Now that a wide-ranged computer network is available throughout Japan, we can
also play the role of the gateway between the US community and Japanese
community.
Could you please send me more information about the X3 Committees?
We are very happy if we can work for the world-wide cooperation of the
Lisp standardization.
Sincerely,
Taiichi Yuasa
Research Institute for Mathematical Sciences,
Kyoto University, Japan
nttlab!kurims!yuasa@Shasta.arpa
∂25-Mar-86 0333 FAHLMAN@C.CS.CMU.EDU Documenting our decisions
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 25 Mar 86 03:21:11 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 25 Mar 86 05:39:05-EST
Date: Tue, 25 Mar 1986 01:59 EST
Message-ID: <FAHLMAN.12193442413.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Guy Steele <gls@AQUINAS.THINK.COM>
Cc: cl-steering@SU-AI.ARPA
Subject: Documenting our decisions
In-reply-to: Msg of 24 Mar 1986 14:37-EST from Guy Steele <gls at THINK-AQUINAS.ARPA>
It seems to me that there are two issues that are somewhat orthogonal:
(a) Can the ANSI effort begin with some form of the Digital press book,
or must a new document begin from scratch?
(b) Should we plan to bring out an interim edition to tide us over to the
point where something officially ANSI comes out (even in draft form)?
If the answer to (a) were yes, that would make everyone's life easier,
but only if we get the manual completely out from under the Digital Press
copyright. I'm assuming that this won't happen. I'd rather spend time
writing a new version than hassling with Digital's lawyers.
On issue (b), I don't think we necessarily need an interim version in
the form of a book. The community of language implementors can track
the emerging standard. For users, the existing book will match the
existing implementations well enough, modulo some ambiguities and minor
fixes. Somewhere along the line we could produce a pamphlet that
documents these disambiguations, to be used with the existing book.
Once the new spec document is ready, according to us, we could find a
way to do a mass printing of it -- we don't need to wait till ANSI and
ISO do their thing.
If the Digital Press book were not the basis for the new standard
document, any second edition of that would be a private matter between
you and Digital Press. My thought was that an updated version of the
Digital Press book could appear just after the proposed standard is
finished. It would explictly point to the standard document as
definitive, but would try to describe the contents of that document in a
form more useful to the average Common Lisp user. The ANSI/ISO document
would be for implementors, language lawyers, and nit pickers.
-- Scott
∂25-Mar-86 0338 OHLANDER@USC-ISIB.ARPA Re: Documenting our decisions
Received: from USC-ISIB.ARPA by SU-AI.ARPA with TCP; 25 Mar 86 03:37:59 PST
Date: 24 Mar 1986 12:26-PST
Sender: OHLANDER@USC-ISIB.ARPA
Subject: Re: Documenting our decisions
From: OHLANDER@USC-ISIB.ARPA
To: Fahlman@C.CS.CMU.EDU
Cc: cl-steering@SU-AI.ARPA
Message-ID: <[USC-ISIB.ARPA]24-Mar-86 12:26:10.OHLANDER>
In-Reply-To: <FAHLMAN.12192630575.BABYL@C.CS.CMU.EDU>
Scott,
I think that your concept of what has to be done to develop
a standard, public domain Common Lisp specification is exactly right.
I don't think copyrights should be assigned to ANSI or ISO or anyone
else that could lay some later claim to them. On the other hand,
it might be important to have a copyright. To do that, perhaps
it should be assigned to a "Common Lisp Users Group",
yet to be established. ISI would be happy to work with you on
developing the documents, to the extent that it is within our
competence to do so. We could certainly take care of
distribution, corrections, updates, etc., once the major writing
work was done.
Ron Ohlander
∂25-Mar-86 1005 gls@THINK-AQUINAS.ARPA Documenting our decisions
Received: from AQUINAS.THINK.COM by SU-AI.ARPA with TCP; 25 Mar 86 10:03:56 PST
Received: from THINK-KATHERINE.ARPA by THINK-AQUINAS.ARPA via CHAOS with CHAOS-MAIL id 17264; Tue 25-Mar-86 13:06:28-EST
Date: Tue, 25 Mar 86 13:06 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Documenting our decisions
To: Fahlman@CMU-CS-C.ARPA
cc: cl-steering@SU-AI.ARPA, gls@THINK-AQUINAS.ARPA
In-Reply-To: <FAHLMAN.12193442413.BABYL@C.CS.CMU.EDU>
Message-ID: <860325130615.7.GLS@THINK-KATHERINE.ARPA>
Date: Tue, 25 Mar 1986 01:59 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
...
Once the new spec document is ready, according to us, we could find a
way to do a mass printing of it -- we don't need to wait till ANSI and
ISO do their thing.
Well, there is $5000 sitting in an escrow account at Digital Press that
can be tapped for such a purpose if we only form a legal entity to
receive it.
If the Digital Press book were not the basis for the new standard
document, any second edition of that would be a private matter between
you and Digital Press. My thought was that an updated version of the
Digital Press book could appear just after the proposed standard is
finished. It would explictly point to the standard document as
definitive, but would try to describe the contents of that document in a
form more useful to the average Common Lisp user. The ANSI/ISO document
would be for implementors, language lawyers, and nit pickers.
If you really think that the ANSI document really would be so incredibly
turgid and opaque that people would rather read the silver book, then
perhaps a second edition would make sense. :-) However, I would rather
see a readable ANSI document plus a good tutorial.
-- Scott
--Guy
∂25-Mar-86 2149 FAHLMAN@C.CS.CMU.EDU Documenting our decisions
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 25 Mar 86 21:48:57 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 26 Mar 86 00:49:47-EST
Date: Wed, 26 Mar 1986 00:49 EST
Message-ID: <FAHLMAN.12193691828.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Guy Steele <gls@AQUINAS.THINK.COM>
Cc: cl-steering@SU-AI.ARPA
Subject: Documenting our decisions
In-reply-to: Msg of 25 Mar 1986 13:06-EST from Guy Steele <gls at THINK-AQUINAS.ARPA>
Well, there is $5000 sitting in an escrow account at Digital Press that
can be tapped for such a purpose if we only form a legal entity to
receive it.
Hmmm... maybe we should create some little noop corporation after all,
to hold the copyright and to handle the cash. It might be useful in
other ways, too. I wonder if a nonprofit corportion that included (for
now) just the steering and technical committee members would be
feasible, and if it would further irritate the rest of the community.
Has anyone had experience in setting up minimal corporations? How hairy
does it get?
If you really think that the ANSI document really would be so incredibly
turgid and opaque that people would rather read the silver book, then
perhaps a second edition would make sense. :-) However, I would rather
see a readable ANSI document plus a good tutorial.
Well, we wouldn't make the ANSI document turgid on purpose, but whenever
a choice had to be made between standards-level clarity and user
friendliness, we would want to go with the former. Maybe such choices
wouldn't arise if we do it right. If you prefer not to work on a second
edition of the silver book and instead to spend the time helping to
polish parts of the ANSI document and/or working on a tutorial, that
would be fine. I suppose then Digital Press would have the right to
hire some random to update the silver book, which certainly has the
potential to confuse things. But probably they wouldn't bother.
-- Scott
∂26-Mar-86 0833 FAHLMAN@C.CS.CMU.EDU FYI
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 26 Mar 86 08:32:50 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 26 Mar 86 11:33:36-EST
Date: Wed, 26 Mar 1986 11:33 EST
Message-ID: <FAHLMAN.12193809028.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-steering@SU-AI.ARPA
Subject: FYI
Apparently my mail to the address below is now reaching Yuasa, with
about 1 day delay in most cases. I've tried to contact Ida, but haven't
heard from him yet. Let's see what we can learn about Common Lisp
politics in Japan, and then discuss what to do about technical committee
membership, etc. Yuasa and Hagiya are knowledgeable, energetic, and
speak pretty good English. Ida is mroe senior and seems to be running
various bureaucratic Common Lisp coordination functions over there. Ida
translated the silver book to Japanese. It may be that we'll want to
invite both Yuasa and Ida to join the technical committee, or just one,
or have them set up a committee over there to mirror what we are doing.
-- Scott
---------------------------------------------------------------------------
Date: Wednesday, 26 March 1986 11:01-EST
From: Scott E. Fahlman <Fahlman>
To: nttlab!kurims!yuasa at SU-SHASTA.ARPA
cc: fahlman
Re: Common Lisp standardization
Dear Mr. Yuasa:
Now that we have established netmail contact, we would very much like to
get the input of you and Mr. Hagiya on the Common Lisp issues we have
been discussing. The first step, if you haven't done this already, is
to send mail to Dick Gabriel "RPG@SU-AI.ARPA" and ask him to add your
name to the Common Lisp mailing list. That is where all the discussions
take palce, and by sending mail to "Common-Lisp@SU-AI" you can respond
to anything you see there or raise your own questions and issues. If
your computer is able to forward messages on this list to others in
Japan, that would be useful, but at least you and Mr. Hagiya should be on
it. Of course, since most people on the list are in the U.S., all the
discussion is in English.
The technical committee that we announced for X3J13 is rather small
(only eight members so far), and this group will be preparing the new
Common Lisp standards document that we will propose for ANSI and ISO
approval. We expect to discuss all the issues on the public
Common-Lisp mailing list, so being on the technical committee is not
important for participating in the debate. The committee members will
vote on what goes into the document if there is not a clear consensus in
the larger community, but I expect this to be very rare. The main job
of the technical committee is to participate in creating the actual
specification document.
We will need to find out more about the situation in Japan before we can
decide how to proceed in adding Japanese menbers to the technical
committee. We may add just one person, who would be responsible for
collecting and representing the views of others in Japan. I'm not sure
whether this should be the person with the most Lisp experience, or if
it is important to choose someone with a high academic rank. We might
add more than one Japanese member to the committee, though we must be
careful not to let the committee get too large and slow-moving. Or
maybe there should be a Japanese committee that would correspond to the
U.S. committee, with close contacts between the two. But until we
decide what to do, we would very much like to get your participation
through the Common Lisp mailing list.
Aside from yourself, Mr. Hagiya, and Professor Ida, are there other
leaders in the Japanese Common Lisp community with whom we should be in
contact? Anything you could tell us about what sorts of Common Lisp
activities have been going on in Japan would be valuable.
Best regards,
Scott Fahlman
∂26-Mar-86 1009 RPG Document
To: cl-steering@SU-AI.ARPA
I don't want people to get the impression that I'm pushing the
Lucid document. We had to prepare it for 2 reasons:
1. A tricky negotiation made it mandatory to include it as
a deliverable for a contract, even though we and others
tried to dissuade the party in question
2. We needed to have a non-generic Common Lisp reference manual.
Because of point 2, this document might not be suitable. Its format
might be nicer for our purposes - 1 function, macro, etc per page,
standard descriptive format. Possibly some clearer prose in places,
possibly worse prose in others. There are legal problems I need to
solve to allow the CL group to muck with the document while Lucid
can continue its rights to the original. I imagine forking the
document somehow, with Lucid keeping rights to the original, but not
to the CL-committee-derived work. I believe Lucid should have no
rights to the ANSI/ISO document.
The book is in Tex format. I have sent a copy to Fahlman to see whether he
believes it's suitable at all before sending it out further.
-rpg-
∂26-Mar-86 1427 FAHLMAN@C.CS.CMU.EDU [OHLANDER: Documenting our decisions]
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 26 Mar 86 14:26:25 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 26 Mar 86 17:27:26-EST
Date: Wed, 26 Mar 1986 17:27 EST
Message-ID: <FAHLMAN.12193873440.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-steering@SU-AI.ARPA
Subject: [OHLANDER: Documenting our decisions]
Forwarded at Ron's request...
Date: Wednesday, 26 March 1986 17:09-EST
From: OHLANDER at USC-ISIB.ARPA
To: Fahlman
Re: Documenting our decisions
Scott,
I agree with your position on the number of people on the
technical committee. I don't want to propose that there be some
significant increase in numbers just to try to
ensure adequate representation for every potentially interested
party. I just wanted to offer a way of dealing with the
perception that some people might have regarding any potential
bias. Actually, I think that the solution that Steve
recently offered (regarding a vendors' reviewing group) is a
much better one than mine.
In regards to the copyright issue, if we have one, some official
body or person has to hold it. We may not have to get a copyright.
However, we have to make sure that there is only one official
public domain specification. Some one or some place has to be
the official repository and maitainer of this document. Otherwise,
why bother with validation and other such issues. A copyright
would achieve this purpose. The other possibility is to maintain
some stamp of approval that is conferred by having originated from
the officially approved maintainer of the document.
Ron
∂26-Mar-86 1500 Moon@ALLEGHENY.SCRC.Symbolics.COM Documenting our decisions
Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 26 Mar 86 15:00:21 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 8602; Mon 24-Mar-86 17:56:29-EST
Date: Mon, 24 Mar 86 17:56 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Documenting our decisions
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>
cc: cl-steering@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12192630575.BABYL@C.CS.CMU.EDU>
Message-ID: <860324175631.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
I have not seen the Lucid manual either, but I know from my own
experience that a language reference manual for users and a formal,
unambiguous language specification are two very different things. In
other words, starting from the Lucid manual may not save a significant
amount of effort.
While TeX and Scribe are both widely available text formatters, and
there may be others, I would like to argue against using any text
formatter at all for the language specification. In this project we
need to concentrate on content, not on style of presentation. Wrestling
with a text formatter would simply be a distraction from our real
business.
But maybe it's better to back off from such implementation
considerations and first decide what it is we're trying to do. Do we
really have the resources within these committees to write a formal,
unambiguous language specification? Or should we be starting by
developing what amounts to an appendix to the Steele manual?
∂26-Mar-86 2026 FAHLMAN@C.CS.CMU.EDU Documenting our decisions
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 26 Mar 86 20:24:36 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 26 Mar 86 23:25:08-EST
Date: Wed, 26 Mar 1986 23:25 EST
Message-ID: <FAHLMAN.12193938558.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: cl-steering@SU-AI.ARPA
Subject: Documenting our decisions
In-reply-to: Msg of 24 Mar 1986 17:56-EST from David A. Moon <Moon at SCRC-STONY-BROOK.ARPA>
I'm not sure that a standard doc has to be very different from a manual,
if the manual is written with sufficient fanaticism. The Steele manual
has been serving us as a de facto spec for awhile now, and it has been
OK for that purpose, if not great. Almost all of the ambiguities are
due to failures on our part to think issues things through and to notice
problems, and not due to the style of presentation. It certainly would
make writing a spec easier if the online text of the Steele book were
available for cannibalization and not legally encumbered. The Lucid
book might serve us just as well in that capacity, except that its text
has not been debugged by the scrutiny of hundreds of users. We will
see.
I agree that we don't want to let text formatting become a big thing in
this effort, at least until the real work is done. But a well-formatted
document with section numbers and an index can be a big help as we go
along.
We obviously don't have the resources to write a formal, 100%
unambiguous language spec. As far as I know, there has never been such
a thing, even for languages much less complex than Lisp. But I think
that if we have a reasonably complete and correct manual to start from,
we'll be able to put together a langauge spec that has many fewer holes
than the original manual, which itself is pretty good except in areas
where all of us were confused or just gave up. Remember that the
original manual was written at a time when there was no implementation
experience with many parts of the language; now we've got the benefit of
some experience, and therefore a much better idea of what things can be
tied down and what things have to be left to implementors. And we
probably won't specify anything that's unimplementable this time.
We could try to write an add-on to the original book, but I think that
this would not be an acceptable form for the standard in the end, and
rewriting could introduce a bunch of new bugs. We're much more likely
to get it right if, at any given time, there's a complete manual
reflecting current truth.
The Europeans think that the best way to build an unambiguous spec is to
define a small kernel as precisely as possible, and then to specify the
rest of the language in terms of that -- by providing example code
implementing the rest of the langauge, I guess. That's a lot of work
too, and has its own set of problems: it's hard to specify just what
elements of the example code are meant to be essential and which can be
changed at the implementor's option. So unless all systems actually use
the example code, you get big problems. I think that a manual is at
least as likely to be unambiguous.
-- Scott
∂27-Mar-86 1946 DLW@SCRC-STONY-BROOK.ARPA Documenting our decisions
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 27 Mar 86 19:42:54 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 448899; Thu 27-Mar-86 18:35:17-EST
Date: Thu, 27 Mar 86 18:38 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: Documenting our decisions
To: Fahlman@C.CS.CMU.EDU
cc: cl-steering@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12193938558.BABYL@C.CS.CMU.EDU>
Message-ID: <860327183849.7.DLW@CHICOPEE.SCRC.Symbolics.COM>
I agree that the resulting text should be readable and sensible, and I
agree that we should not strive for a 100% unambiguous spec; we don't
want to end up with a Vienna Definition Language monster like the PL/I
definition. I also agree that we can do a lot better now than we did
last time, partly because we know more about what we're doing.
However, there's another major reason for ambiguities besides the ones
you mentioned: interactions between features. Yes, there are
declarations. Yes, there are FLET and MACROLET. Exactly how do the two
work together? This isn't the greatest example, but I'm sure you know
what I mean. I think that to clear up such problems, the manual will
have to get somewhat more rigorous, and it will probably be necessary to
introduce more terminology with strict definitions.
As was pointed out, the stricter it gets, the harder it is to make the
text flow smoothly and be easy to understand. But I agree that we need
to err on the side of clarity and unambiguity, and keep the writing as
clear as we can in light of that. There's no getting around the fact
that excellent technical writing is difficult.
You're right about the kernel definition. To put it another way, a spec
written that way would be extremely constrictive, since you'd have to
imitate every single aspect of the behavior of the example code,
including its behavior on bad inputs, etc. The Common Lisp spec
explicitly takes the attitude that it only specifies certain behavior,
and other things are termed "an error". Sure, things would be more
portable and unambiguous if we didn't take that attitude, but it has
been our feeling that implementations would be forced into unacceptable
inefficiencies and compromises by such a strict spec.
Of course, now that we know more about implementations, we could
reconsider some of the "is an error" cases, and consider defining them.
However, given our agenda and priorities, I don't know whether it's
worth spending time on that in any significant number of cases. We
could keep it in the backs of our minds, though.
∂27-Mar-86 1955 DLW@SCRC-STONY-BROOK.ARPA [yuasa: forwarded]
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 27 Mar 86 19:54:57 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 448914; Thu 27-Mar-86 18:50:03-EST
Date: Thu, 27 Mar 86 18:53 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: [yuasa: forwarded]
To: Fahlman@C.CS.CMU.EDU, cl-steering@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12193149846.BABYL@C.CS.CMU.EDU>
Message-ID: <860327185339.9.DLW@CHICOPEE.SCRC.Symbolics.COM>
I concur with you about the various Japanese folks. The Japanese are
definitely status-conscious. I also found out when I was there that
they are age-conscious, and assume a strong monotonic depedency between
age and level of responsibility. (As a "high-ranking" Symbolics
technical person, I found out that they were surprised that I was
apparently only in my late thirties, and they were even more surprised
when they found out I was in my late twenties. From what I've read,
this is pretty standard.)
I should also point out that Prof. Ida has specifically been active in
getting Common Lisp established as a standard within JEIDA. It's hard
to explain what JEIDA is exactly, both because I don't know, and because
Japanese organizations and their roles do not map into American ones.
It's an industry organization. It's probably sort of like EIA or IEEE
in some ways, at least insofar as it's a forum for adoptation of
standards. In any case, the fact that Ida is involved in JEIDA is
probably another reason that it makes sense for him to be involved with
the Common Lisp standardization process.
Unfortunately, I don't know how much he really knows technically. It
would be very hard to justify his inclusion on the technical committee
on the basis of his deep knowledge of Lisp and Lisp implementation
issues, based on what I know. I could be wrong.
Here's a random idea: perhaps he really belongs on the steering
committee, and he could help us figure out who in Japan makes sense for
the technical committee?
∂27-Mar-86 2220 FAHLMAN@C.CS.CMU.EDU [yuasa: forwarded]
Received: from [128.2.255.254] by SU-AI.ARPA with TCP; 27 Mar 86 22:18:50 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 28 Mar 86 01:18:49-EST
Date: Fri, 28 Mar 1986 01:18 EST
Message-ID: <FAHLMAN.12194221400.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "Daniel L. Weinreb" <DLW@SCRC-QUABBIN.ARPA>
Cc: cl-steering@SU-AI.ARPA
Subject: [yuasa: forwarded]
In-reply-to: Msg of 27 Mar 1986 18:53-EST from Daniel L. Weinreb <DLW at SCRC-QUABBIN.ARPA>
Unfortunately, I don't know how much he really knows technically. It
would be very hard to justify his inclusion on the technical committee
on the basis of his deep knowledge of Lisp and Lisp implementation
issues, based on what I know. I could be wrong.
Well, we don't necessarily have to apply exactly the same standards to
foreign members that we did to American members. But I share your lack
of knowledge about Ida's technical abilities, and his English is
certainly not good enough for him to help write the manual or choose the
wording. Then again, he may be the guy who ends up translating the
thing into Japanese.
Here's a random idea: perhaps he really belongs on the steering
committee, and he could help us figure out who in Japan makes sense for
the technical committee?
I thought about proposing that myself. He seems to enjoy hacking
bureaucracy. So far, two of the addresses I've tried for mail to Ida
have bounced, and the third has not yet produced a reply.
-- Scott
∂28-Mar-86 0808 GRISS%HP-HULK@hplabs.ARPA Ida
Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 28 Mar 86 08:08:29 PST
Received: from HP-HULK by hplabs.ARPA ; Fri, 28 Mar 86 08:07:53 pst
Date: Fri 28 Mar 86 08:09:22-PST
From: Martin <GRISS%HP-HULK@hplabs.ARPA>
Subject: Ida
To: cl-steering%su-ai@HPLABS
Cc: GRISS%HP-HULK@HPLABS
I would be concerned with adding another person to the steering committee
at this point. I thing you would then also have to consider some
additions from the European communitee and so on, possible leading to
a rather large group.
I think we would do better to identify a serious technical person, or
a more senior person, such as Eichi Goto, who is extremely well known
in the LISP, Alabgra and AI communitee in Japan. Goto has been
involved with numerous LISP implementations, both software and
hardware.
I will dig around for some of the articles I have, maybe can find some
new names.
M
-------
∂28-Mar-86 0948 RPG New Members
To: cl-steering@SU-AI.ARPA
I agree with Griss and the others who recommended more senior
Japanese members. I met with the KCL folks last year and found
that their understanding of Lisp was surprisingly shallow for
implementors. They seemed quite capable of hacking extraordinary
things together, but lacked the judgement to decide among various
interpretations of Silver-book statements by relying on taste and
a feeling for Lisp. I don't believe that at the point I met with
them they had developed a consistent mental model of Common Lisp.
-rpg-
∂28-Mar-86 1008 OHLANDER@USC-ISIB.ARPA Re: [yuasa: forwarded]
Received: from USC-ISIB.ARPA by SU-AI.ARPA with TCP; 28 Mar 86 10:07:44 PST
Date: 28 Mar 1986 09:03-PST
Sender: OHLANDER@USC-ISIB.ARPA
Subject: Re: [yuasa: forwarded]
From: OHLANDER@USC-ISIB.ARPA
To: Fahlman@C.CS.CMU.EDU
Cc: cl-steering@SU-AI.ARPA
Message-ID: <[USC-ISIB.ARPA]28-Mar-86 09:03:51.OHLANDER>
In-Reply-To: <FAHLMAN.12194221400.BABYL@C.CS.CMU.EDU>
Perhaps the best place for Ida is on the ISO committee. I think
that the Japanese might regard this as an honorable position. It
would also offer the opportunity to interract with the technical
committee.
Ron
∂28-Mar-86 1255 FAHLMAN@C.CS.CMU.EDU New Members
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 28 Mar 86 12:54:11 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 28 Mar 86 15:54:57-EST
Date: Fri, 28 Mar 1986 15:54 EST
Message-ID: <FAHLMAN.12194380895.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-steering@SU-AI.ARPA
Subject: New Members
In-reply-to: Msg of 28 Mar 1986 12:48-EST from Dick Gabriel <RPG at SU-AI.ARPA>
OK, I can see the wisdom of considering Yuasa and Hagiya as too junior
to the the official Japanese reps, if there are to be only one or two.
Maybe even Ida is too junior -- he's young and an associate professor, I
think. The problem with taking on Goto or someone more senior is that
we want to make sure that whoever we get has some serious interest in
Common Lisp and the standardization thereof. We don't need some
VIP who thinks that Lisp is a cute toy and not very practical.
I think that the KCL guys have a lot of enthusism and energy that we
want to tap, and also good contacts over there. So we want to keep them
involved and feeling good about all this, even if they're not the
official Japanese representatives.
The model I keep coming back to in my mind is trying to get the Japanese
to set up their own committee over there, with much communication with
ours, and that we all come together at ISO. That way N Japanese can get
into the act and they can sort out their own politics.
-- Scott
∂28-Mar-86 2041 DLW@SCRC-STONY-BROOK.ARPA Ida
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 28 Mar 86 20:41:39 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 449977; Fri 28-Mar-86 20:07:43-EST
Date: Fri, 28 Mar 86 20:09 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: Ida
To: GRISS%HP-HULK@HPLABSD.ARPA, cl-steering@SU-AI.ARPA
In-Reply-To: The message of 28 Mar 86 11:09-EST from Martin <GRISS%HP-HULK@hplabs.ARPA>
Message-ID: <860328200946.8.DLW@CHICOPEE.SCRC.Symbolics.COM>
I agree about finding a more senior person. I also agree with RPG about
Hagiya and Yuasa; I like them and am impressed by their accomplishments,
but their misunderstandings of the manual in a few placed clearly
indicated to me that while they certainly could implement from a spec,
they didn't have a good idea why the spec was the way it was.
On the other hand, let's be quite careful about the kind of person we
choose: it has to be someone who appreciates what it means to write a
substantial program in Lisp, not just someone who has implemented a Lisp
of some sort. I am afraid of choosing someone who is too much of a
theoretist, who would not have the sensitivity to make a good
engineering compromise between elegance and practicality. We should
keep this in mind, and be careful that we know enough about someone
before we put him on the committee that we can be confident he can
work in that kind of engineering milieu.
∂28-Mar-86 2157 JMC Japanese representative
To: cl-steering@SU-AI.ARPA
Japanese support for a Common Lisp standard would be valuable. My
suggestion is that members of the committee discuss with some senior
Japanese, who is himself not a candidate, what kind of person is
desirable and be substantially influenced by the advice obtained.
∂29-Mar-86 0806 FAHLMAN@C.CS.CMU.EDU Japanese representative
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 29 Mar 86 08:06:43 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 29 Mar 86 11:07:27-EST
Date: Sat, 29 Mar 1986 11:07 EST
Message-ID: <FAHLMAN.12194590697.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: John McCarthy <JMC@SU-AI.ARPA>
Cc: cl-steering@SU-AI.ARPA
Subject: Japanese representative
In-reply-to: Msg of 29 Mar 1986 00:57-EST from John McCarthy <JMC at SU-AI.ARPA>
That sounds like a good idea. Do you have any such high-level contacts
in Japan? I could probably get some names from Herb Simon and others
around here, but having a personal contact would probably be best.
-- Scott
∂29-Mar-86 0809 FAHLMAN@C.CS.CMU.EDU Random note
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 29 Mar 86 08:09:23 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 29 Mar 86 11:10:14-EST
Date: Sat, 29 Mar 1986 11:10 EST
Message-ID: <FAHLMAN.12194591209.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-steering@SU-AI.ARPA
Subject: Random note
I'll be out of the country from April 1 - 9, so don't wait around for my
input if decisions have to be made. I've got about two weeks of
intensive work to do when I get back, but I'm hoping we can really get
rolling on technical issues starting in May.
-- Scott
∂29-Mar-86 0828 DLW@SCRC-STONY-BROOK.ARPA New Members
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 29 Mar 86 08:28:10 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 450156; Sat 29-Mar-86 11:25:26-EST
Date: Sat, 29 Mar 86 11:27 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: New Members
To: cl-steering@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12194380895.BABYL@C.CS.CMU.EDU>
Message-ID: <860329112735.3.DLW@CHICOPEE.SCRC.Symbolics.COM>
From what I've learned about the Japanese, I think it's safe to say that
none of us have any hope of having a good understanding of their
internal politics, questions of what's appropriate, who would be
insulted by what, and so on. Fahlman's suggestion re their own
committee, or McCarthy's of consulting with someone there, both sound
reasonable to me, and certainly better than our making a direct choice
of an individual ourselves.
∂01-Apr-86 0735 FAHLMAN@C.CS.CMU.EDU Docmenting the decisions
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 1 Apr 86 07:35:41 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 1 Apr 86 10:36:10-EST
Date: Tue, 1 Apr 1986 10:36 EST
Message-ID: <FAHLMAN.12195371441.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-steering@SU-AI.ARPA
Subject: Docmenting the decisions
I have now received a hrdcopy of the Lucid manual, and it looks like a
good starting point for the ANSI document, assuming that RPG's lawyers
can work out a release on the rights that will still retain for Lucid
the right to use their own work. The book is organized as a chunk of
introductory text on each chapter, followed by alphabetical listings of
functions and variables in that section, one per page.
We would have to remove a modest amount of Lucid-specific stuff, and put
in a fair amount of work to indicate the range of permissible variation
on some issues -- Lucid's book just says what their Lisp does. Some of
the introductory sections will have to be beefed up a bit, and the right
to incorporate some excepts from Steele's book would be valuable here.
A lot of these things Guy got just right.
Let me propose that the following thigns take place int he next 10 days
while I'm out of town:
1. Bob Mathis will communicate with the ANSI and ISO people and find out
whether the following kinds of status for a spec document are
acceptable to them:
(a) A public-domain document. Anyone would be able to print this and we
couldn't use legal means to prevent them from modifying it. But if the
copy came from us or from ANSI, people would know it is definitive. I
favor this option if we can do it this way -- gets the lawyers out of
the loop for good.
(b) A document copyrighted by a small non-profit corporation set up
specifically for this purpose (e.g. The Common Lisp Ad Hoc Technical
Committee, Inc.). We would prefer not to assign the copyright to ANSI,
but would of course grant to ANSI and to the rest of the community
blanket permission to reproduce the document without making hidden
modifications. Blanket permission would also be given for incorporating
the document into online documentation.
(c) Some other scheme of their choice.
2. RPG will continue his efforts to find a way to release the version
modified by the technical committee into the public domain (or to
assign the copyright to this new organization), while retaining for
Lucid the rights they need.
3. Steele will ask Digital Press if they are willing to grant permission
for this document to incorporate substantial excerpts from the Digital
Press book (but less than 30% of it), given that the result is to be
handled as 1a or 1b.
Suitable acknowledgement would of course be given to the contribution of
Lucid and Digital Press. I don't think the other companies cna object
to that, though if the document is public domain they could quietly
leave this off in their own copies. We would encourage other companies
not to do this, however.
Once all this is settled, I'm willing to collect the files at CMU and
start to roll on this. It seems reasonable to me that we set a goal of
September 1 for having a document with the backlog of small problems
cleaned up, and that we try to settle everything else and get a document
to ANSI by Dec 31, 1986. But we need to discuss this schedule further.
Someone on the steering committee needs to take charge of this business
of collecting the names of all participating companies. We may also
want to hold elections soon within the committess, as we'll have to tell
ANSI what our sturcutre is.
-- Scott
∂01-Apr-86 1358 ALAN@MC.LCS.MIT.EDU Docmenting the decisions
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 1 Apr 86 13:57:56 PST
Date: Tue, 1 Apr 86 17:00:02 EST
From: Alan Bawden <ALAN@MC.LCS.MIT.EDU>
Subject: Docmenting the decisions
To: Fahlman@C.CS.CMU.EDU
cc: cl-steering@SU-AI.ARPA
In-reply-to: Msg of Tue 1 Apr 1986 10:36 EST from Scott E. Fahlman <Fahlman at C.CS.CMU.EDU>
Message-ID: <[MC.LCS.MIT.EDU].868790.860401.ALAN>
Before anyone makes any decisions about starting with Lucid's book, perhaps
we should all have a look at it?
∂03-Apr-86 1412 MATHIS@USC-ISIF.ARPA Documenting...
Received: from USC-ISIF.ARPA by SU-AI.ARPA with TCP; 3 Apr 86 14:11:30 PST
Date: 3 Apr 1986 14:11-PST
Sender: MATHIS@USC-ISIF.ARPA
Subject: Documenting...
From: MATHIS@USC-ISIF.ARPA
To: cl-steering@SU-AI.ARPA
Cc: Mathis@USC-ISIF.ARPA
Message-ID: <[USC-ISIF.ARPA] 3-Apr-86 14:11:16.MATHIS>
This message is in response to previous messages on the topics of
"Getting things rolling" and "Documenting our decisions"; I raise
three points -- a trip to Paris on May 5 to meet with the EU←LISP
Committee, some information on copyrights and ANSI standards, and
what is the central essence of Common Lisp?
Committee organization -- I think I was drafted to do the
organizational and administrative work associated with the
steering committee. I'll keep doing that. As to a formal
meeting; I don't think one is necessary yet.
I will send out a message requesting (again) the identification
of people and companies participating in this process. This will
probably need to be done two or three more times before the end
of 1986.
As to ARPA net access; there are some possibilities that people
on the Source or CompUServe or MCI-Mail may be able to
communicate with ARPA net mail in ways similar to USE net or
CSnet. ARPA net access may only be a temporary problem and as
such Steph Squires seemed willing to help with any real needs.
I will probably attend the May 5 meeting of the EU←LISP committee
in Paris. On administrative and standards issues, I feel
prepared; on technical issues, I need some guidance. I talked to
Chailloux this morning and I expect to have a couple of other
discussions before the trip. He always seems reasonable and
willing to talk.
What is the central essence of Common Lisp? If I had a better
understanding of this, I think I could understand the European
"levels" approach better. There is more to it than just the name
given to a particular function or how a particular function is
specified or how it is implemented or made available to a user.
Those kinds of things can be worked out. More difficult are
fundamental things (for example, how scopes are handled). Is
there a list of what the fundamental concepts or approaches are?
This is also linked to the question of validation. What does it
take to be considered a Common Lisp implementation? Is there a
minimal acceptable level?
Are there other things I should consider in meeting with the
EU←LISP group? Does anyone else want to go?
Another issue that has been raised is the copyright and
availability of the final standard. In general ANSI holds the
copyright to their standards. They also want to encourage the
use of their standards and don't want copyright problems to stand
in the way. When something is in the public domain, there is no
control over its use. I think what we are really interested in
is a pre-arranged, royalty-free permission to use.
I talked to Cathy Kachurik of X3 about this copyright situation.
She has already contacted Digital Press and they seem willing to
turn over the right to produce a derived work. That would free
us to use as much or as little from the Steele book as is now
thought appropriate.
We should begin to make a list of the kinds of things we want
people to be able to do with the standard -- provide machine
readable copies with a language processor, incorporate it into
automatic documentation or help systems, reprint sections in
manuals or text books, and so forth. I think it is best that we
come up with such a list and then build it into the overall plan
of work for X3J13. We will also have to arrange for distribution
of any versions other than the ANSI printed one. ISI may be the
best for the "standard" one and CMU for "enhanced or modified or
working" versions.
-- Bob Mathis
∂03-Apr-86 1727 OHLANDER@USC-ISIB.ARPA Re: Documenting...
Received: from USC-ISIB.ARPA by SU-AI.ARPA with TCP; 3 Apr 86 17:27:23 PST
Date: 3 Apr 1986 17:27-PST
Sender: OHLANDER@USC-ISIB.ARPA
Subject: Re: Documenting...
From: OHLANDER@USC-ISIB.ARPA
To: MATHIS@USC-ISIF.ARPA
Cc: cl-steering@SU-AI.ARPA
Message-ID: <[USC-ISIB.ARPA] 3-Apr-86 17:27:08.OHLANDER>
In-Reply-To: <[USC-ISIF.ARPA] 3-Apr-86 14:11:16.MATHIS>
In regards to Arpanet access, ISI is working on a commercial mail
system that will allow access to the Arpanet through commercial
systems such as MCI-mail, Telemail, etc. We already have a
prototype working with quite a few users, including a number of
people from IEEE executive and steering committees. We
expect the final system to be ready within the next 3 months.
Ron Ohlander
∂04-Apr-86 0820 gls@THINK-AQUINAS.ARPA Documenting...
Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 4 Apr 86 08:18:37 PST
Received: from katherine by GODOT.THINK.COM via CHAOS; Fri, 4 Apr 86 11:18:56 est
Date: Fri, 4 Apr 86 11:20 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Documenting...
To: MATHIS@USC-ISIF.ARPA, cl-steering@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: <[USC-ISIF.ARPA] 3-Apr-86 14:11:16.MATHIS>
Message-Id: <860404112031.3.GLS@THINK-KATHERINE.ARPA>
Date: 3 Apr 1986 14:11-PST
From: MATHIS@USC-ISIF.ARPA
...
Another issue that has been raised is the copyright and
availability of the final standard. In general ANSI holds the
copyright to their standards. They also want to encourage the
use of their standards and don't want copyright problems to stand
in the way. When something is in the public domain, there is no
control over its use. I think what we are really interested in
is a pre-arranged, royalty-free permission to use.
I talked to Cathy Kachurik of X3 about this copyright situation.
She has already contacted Digital Press and they seem willing to
turn over the right to produce a derived work. That would free
us to use as much or as little from the Steele book as is now
thought appropriate. ...
I have just spoken with John Osborn of Digital Press on this subject.
He was apparently concerned about whether I was concerned about it--in
other words, the usual problem of obtaining N-person consensus using
only 2-person communications links. I assured him that I wanted the
ANSI committee to be able to use the contents of CLtL unimpeded. He
said that Digital Press is agreeable to an arrangement whereby ANSI
receives permission royalty-free to use any or all contents of CLtL for
the purposes of developing a Common Lisp standard (while Digital Press
retains the right to publish present and future editions of the existing
book). He said Digital Press is still making piles of money on CLtL and
would like to continue to do so, and suggested that future editions
might be more "personal" or "tutorial" or whatever. I pointed out that
that was reasonable, but also that I would likely be involved in the
ANSI effort as well. (I still have some concerns about potential
confusion over which book is the official Common Lisp; if CLtL continues
into future editions, I think it must change its character so as not to
be confusable with the ANSI standard.)
Apparently other parts of DEC (Gary Brown's name was mentioned) are
putting mild pressure on Digital Press to cooperate with ANSI, so maybe
it will all go smoothly after all.
If Lucid is still willing to make its text available, then the committee
will have some useful choices about which text to draw on for what
purposes. (I too would like to see the text, by the way, Dick.)
--Guy
P.S. Lucid's document uses TeX, and I am in process of converting CLtL
from SCRIBE to TeX, so maybe the committee will want to work with TeX
files. I have some nifty macros: all you need to say is
\begin{defun}
complex realpart &optional imagpart
The arguments must be non-complex numbers...
\end{defun}
and the function description headers are formatted (fonts and line
breaks) automatically. There are similar facilities for macros, etc.
--Q
∂10-Apr-86 2008 FAHLMAN@C.CS.CMU.EDU Documenting...
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 10 Apr 86 20:08:38 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 10 Apr 86 23:09:21-EST
Date: Thu, 10 Apr 1986 23:09 EST
Message-ID: <FAHLMAN.12197867848.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-steering@SU-AI.ARPA
Subject: Documenting...
In-reply-to: Msg of 4 Apr 1986 11:20-EST from System Files <SYS at SU-AI.ARPA>
I have just spoken with John Osborn of Digital Press on this subject.
...
He said that Digital Press is agreeable to an arrangement whereby ANSI
receives permission royalty-free to use any or all contents of CLtL for
the purposes of developing a Common Lisp standard (while Digital Press
retains the right to publish present and future editions of the existing
book).
This is great news. We will want to go over the current manual very
carefully, and maybe change its format, on the way to a standard, but
the ability to use chunks of the Digital Press text verbatim along with
parts of the Lucid version will save a lot of work.
(I still have some concerns about potential
confusion over which book is the official Common Lisp; if CLtL continues
into future editions, I think it must change its character so as not to
be confusable with the ANSI standard.)
I don't think that this will be a problem. All future Digital Press
editions should explicitly state that the ANSI standard, once adopted,
is definitive, and the ANSI version should have eagles and other
Official Looking Stuff on the cover.
-- Scott
∂18-Apr-86 1922 squires@ipto.ARPA Japanese representative
Received: from IPTO.ARPA by SU-AI.ARPA with TCP; 18 Apr 86 19:22:30 PST
Received: by ipto.ARPA (4.12/4.7)
id AA18291; Fri, 18 Apr 86 22:23:30 est
Date: Fri 18 Apr 86 22:23:22-EST
From: Stephen Squires <SQUIRES@IPTO.ARPA>
Subject: Japanese representative
To: cl-steering@SU-AI.ARPA
Message-Id: <VAX-MM(187)+TOPSLIB(118) 18-Apr-86 22:23:22.IPTO.ARPA>
About a year ago Bob Balzer introduced me to a prominate member of the
Japanese computer science community (Kouichi) at an international program
committee meeting.
I asked Balzer to contact him and ask him to suggest a candidate for
the technical committee. We need to get more specfics about this candidate.
I have asked Balzer to tell me what he knows. The following messages
embody what has happened to date:
Friday, April 18, 1986 22:14:29-EST
339 18-Apr BALZER@ISI-VAXA Suggested Japanese representative (1149 chars)
Message 339 -- ************************
18-Apr-86 20:21:27-EST,1149;000000000000
Received: from USC-ISI.ARPA by ipto.ARPA (4.12/4.7)
id AA18175; Fri, 18 Apr 86 20:21:21 est
Received: FROM ISI-VAXA.ARPA BY USC-ISI.ARPA WITH TCP ; 18 Apr 86 20:16:10 EST
Received: by isi-vaxa.ARPA (4.12/4.7)
id AA10497; Fri, 18 Apr 86 17:17:09 pst
Message-Id: <8604190117.AA10497@isi-vaxa.ARPA>
Date: 18 Apr 1986 1717-PST (Friday)
To: SQUIRES@USC-ISI.ARPA
From: BALZER@ISI-VAXA.ARPA
Subject: Suggested Japanese representative for Common Lisp
-------------- Begin Forwarded Message --------------
TO: BALZER@ISI-VAXA
FROM: PACRAIG@USC-ISIB
SENDER: PACRAIG@USC-ISIB
SUBJECT: Kouichi called....
RECEIVED: 4/18/86 15:13:45
SENT: 4/18/86 15:03:00
MESSAGE-ID: <[USC-ISIB.ARPA]18-Apr-86 15:03:51.PACRAIG>
TO: Balzer@ISI-VAXA.ARPA
FROM: Patti Craig <PACraig@USC-ISIB.ARPA>
SENDER: PACRAIG@USC-ISIB.ARPA
RECEIVED: from USC-ISIB.ARPA by isi-vaxa.ARPA (4.12/4.7)
RETURN-PATH: <PACRAIG@USC-ISIB.ARPA> id AA09323; Fri, 18 Apr 86 15:05:56 pst
Following is the reference/name you wanted:
Masayuki Ida
Computer Science Laboratory
Aoyama Gakuin University
1626 Ono, Atugi City
Kanagawa 234-01
Japan
Phone: 462-48-1221, ext. 4526
Electronic Mail: IDA%utokyo-relay.csnet@csnet-relay.arpa
-------
∂18-Apr-86 1925 squires@ipto.ARPA Re: Suggested Japanese representative for Common Lisp
Received: from IPTO.ARPA by SU-AI.ARPA with TCP; 18 Apr 86 19:25:48 PST
Received: by ipto.ARPA (4.12/4.7)
id AA18306; Fri, 18 Apr 86 22:26:31 est
Date: Fri 18 Apr 86 22:26:26-EST
From: Stephen Squires <SQUIRES@IPTO.ARPA>
Subject: Re: Suggested Japanese representative for Common Lisp
To: BALZER@ISI-VAXA.ARPA
Cc: SQUIRES@USC-ISI.ARPA, SQUIRES@IPTO.ARPA
Message-Id: <VAX-MM(187)+TOPSLIB(118) 18-Apr-86 22:26:26.IPTO.ARPA>
In-Reply-To: Message from "BALZER@ISI-VAXA.ARPA" of 18 Apr 1986 1717-PST (Friday)
Thanks for the reference. What do you know about person suggested? The
steering group has estabished some guidelines for membership. How do
could the steering committee get the additional specifics that they
need to know?
-------
∂19-Apr-86 1404 FAHLMAN@C.CS.CMU.EDU Japanese representative
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 19 Apr 86 14:01:56 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 19 Apr 86 17:03:46-EST
Date: Sat, 19 Apr 1986 17:03 EST
Message-ID: <FAHLMAN.12200160588.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Stephen Squires <SQUIRES@IPTO.ARPA>
Cc: cl-steering@SU-AI.ARPA
Subject: Japanese representative
Steve,
Masayuki Ida is in fact the person we have been discussing as the most
likely Japanese candidate all along, but it's nice to know that Koiuchi
also feels that he's the obvious guy. Our major reservation was that he
might be too junior, so selecting him might be viewed as some sort of
insult.
Ida is the guy who translated Steeele's book into Japanese, and he has
been working on various Common Lisp standardization efforts over there,
including proposals for a subset and for an extension to Kanji
characters and strings. Apparently the focus of Common Lisp activity
over there is a committee within JEIDA (Japanese Electronics Industry
Development Association), which has been running for about a year with
Ida as the chairman.
Ida was recently promoted to associate professor at Aoyama Gakuin
University -- I'm not sure where that university is in the fairly
well-defined Japanese pecking order. He speaks adequate English for
communication, though he's not very fluent -- see his recent note to the
Common Lisp mailing list. He now seems to be able to send and recieve
netmail via CSnet with about a half-day latency.
Let me propose the following model, which we can bounce off of the
various senior Japanese contacts that we have to see what they think
about it:
1. Any individual in Japan who has a stable netmail connection to the
U.S. and an interest in the standardization of Common Lisp is encouraged
to join the Common Lisp mailing list and to participate in the
discussions. (Apparently a rebroadcast point is being established at
NTT, so that one message can be sent there and can be forwarded to
everyone on JUNET. However, Ida prefers to get direct mail via CSNET to
U-Tokyo.)
2. The committee within JEIDA should continue to be the focus for
Japanese Common Lisp activities. In the future, we will attempt to stay
in much closer contact with this group via netmail.
3. Though any number of Japanese researchers can participate in our
design discussions via the Common Lisp mailing list, we invite the JEIDA
committee to elect one representative to sit on our technical committee,
and one person (it may be the same person) to sit on our steering
committee for the purposes of formal liaison between the two groups.
The choice is up to them. (I wouldn't be surprised if Ida were
selected.)
If we agree that this is a reasonable model, the next step would be for
people who know the leading CS people in Japan to solicit their opinion
of this. It has the advantage that we're not telling them who to nominate,
so we don't have to weigh seniority against interest and knowledge; the
disadvantage is that we might get someone inappropriate from our point
of view, but I think it unlikely that any of these people will poison
the process.
-- Scott
∂20-Apr-86 0838 GRISS%HP-HULK@hplabs.ARPA Japanese Representative
Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 20 Apr 86 08:36:44 PST
Received: from HP-HULK by hplabs.ARPA ; Sun, 20 Apr 86 08:26:18 pst
Date: Sun 20 Apr 86 08:23:51-PST
From: Martin <GRISS%HP-HULK@hplabs.ARPA>
Subject: Japanese Representative
To: cl-steering@su-ai.ARPA
Cc: GRISS%HP-HULK@HPLABS
I like Scott's proposal. I would be prepared to discuss it with E.
Goto fo
∂20-Apr-86 0900 FAHLMAN@C.CS.CMU.EDU Japanese Representative
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 20 Apr 86 09:00:27 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 20 Apr 86 12:02:33-EST
Date: Sun, 20 Apr 1986 12:02 EST
Message-ID: <FAHLMAN.12200367902.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Martin <GRISS%HP-HULK@HPLABS.ARPA>
Cc: cl-steering@SU-AI.ARPA
Subject: Japanese Representative
In-reply-to: Msg of 20 Apr 1986 11:23-EST from Martin <GRISS%HP-HULK at hplabs.ARPA>
Martin,
Your message got truncated, but I believe that you were offering to
discuss the proposal for Japanese participation with Goto. If nobody
within our steering/technical committee objects to the proposal in the
next couple of days, then I think it would be very useful for you to
sound out Goto on this.
One concern I have is whether the JEIDA committee is viewed by people
like Goto as the legitimate body to represent the Japanese Common Lisp
community. I have no reason to believe it is not, but we don't want to
inadvertently take sides in some power struggle over there by throwing
our weight behind Ida's committee. It couldn't hurt to ask.
Thanks for offering to follow up on this.
-- Scott
∂20-Apr-86 1001 RPG Chairman
To: cl-steering@SU-AI.ARPA
I think it is time that we nominate a chairman of the Steering
committee. Because Bob Mathis knows all the proper steps to take,
because he has done this sort of thing before, and because he has
the international connections to pull it all off, I think we should
elect him our chairman.
-rpg-
∂20-Apr-86 1231 GRISS%HP-HULK@hplabs.ARPA Re: Chairman
Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 20 Apr 86 12:25:51 PST
Received: from HP-HULK by hplabs.ARPA ; Sun, 20 Apr 86 12:26:27 pst
Date: Sun 20 Apr 86 12:26:13-PST
From: Martin <GRISS%HP-HULK@hplabs.ARPA>
Subject: Re: Chairman
To: RPG@SU-AI.ARPA, cl-steering@SU-AI.ARPA
Cc: GRISS%HP-HULK@HPLABS
In-Reply-To: Message from "Dick Gabriel <RPG@SU-AI.ARPA>" of Sun 20 Apr 86 10:01:00-PST
Return-Path: <RPG@SU-AI.ARPA>
Received: from hplabs.ARPA by HP-HULK with TCP; Sun 20 Apr 86 12:21:17-PST
Received: from SU-AI.ARPA by hplabs.ARPA ; Sun, 20 Apr 86 10:05:10 pst
Date: 20 Apr 86 1001 PST
From: Dick Gabriel <RPG@SU-AI.ARPA>
Subject: Chairman
To: cl-steering@SU-AI.ARPA
I think it is time that we nominate a chairman of the Steering
committee. Because Bob Mathis knows all the proper steps to take,
because he has done this sort of thing before, and because he has
the international connections to pull it all off, I think we should
elect him our chairman.
-rpg-
I agree
mlg
-------
∂20-Apr-86 1256 GRISS%HP-HULK@hplabs.ARPA Japanese Representative
Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 20 Apr 86 12:56:09 PST
Received: from HP-HULK by hplabs.ARPA ; Sun, 20 Apr 86 12:56:27 pst
Date: Sun 20 Apr 86 08:23:51-PST
From: Martin <GRISS%HP-HULK@hplabs.ARPA>
Subject: Japanese Representative
To: cl-steering@su-ai.ARPA
Cc: GRISS%HP-HULK@HPLABS
I like Scott's proposal. I would be prepared to discuss it with E.
Goto for his feedback.
M
-------
∂21-Apr-86 0844 MATHIS@USC-ISIF.ARPA message from/re Ida
Received: from USC-ISIF.ARPA by SU-AI.ARPA with TCP; 21 Apr 86 08:44:08 PST
Date: 21 Apr 1986 08:46-PST
Sender: MATHIS@USC-ISIF.ARPA
Subject: message from/re Ida
Subject: [Masayuki Ida <tansei!a37078%utokyo-relay.csnet@CSNET-RELAY...]
From: MATHIS@USC-ISIF.ARPA
To: cl-steering@SU-AI.ARPA
Message-ID: <[USC-ISIF.ARPA]21-Apr-86 08:46:29.MATHIS>
Here is a message I received from Masayuki Ida last week. I
think it was partially in response to my separate ISO work to
generate international participation. The Professor Ikuo Nakata
that he mentions is the head of the Japanese delegation to
ISO/TC97/SC22 (the immediate group under which our ISO working
group would operate). Nakata's recommendation means that we
should find a place for Ida. There may be other appropriate
Japanese too (I think this is the point of Fahlman's message on
20 April).
-- Bob
Begin forwarded message
Received: FROM CSNET-RELAY.ARPA BY USC-ISIF.ARPA WITH TCP ; 15 Apr 86 08:41:33 PST
from utokyo-relay by csnet-relay.csnet id ak10810; 15 Apr 86 11:33 EST
by u-tokyo.junet (4.12/4.9J-1[JUNET-CSNET])
id AA06290; Tue, 15 Apr 86 19:40:40+0900
by tansei.u-tokyo.junet (4.12/4.9J)
id AA10384; Fri, 11 Apr 86 18:31:07+0900
Date: Fri, 11 Apr 86 18:31:07+0900
From: Masayuki Ida <tansei!a37078%utokyo-relay.csnet@CSNET-RELAY.ARPA>
To: ida@utokyo-relay.CSNET, mathis%usc-isif.arpa@CSNET-RELAY.ARPA
Subject: I am the chair of the Common Lisp committee of Japan
Return-Path: <tansei!a37078%utokyo-relay.csnet@CSNET-RELAY.ARPA>
Message-ID: <8604110931.AA10384@tansei.u-tokyo.junet>
Dear Dr. Bob Mathis;
It is the first letter to you.
Let me introduce myself. I am charing the common Lisp committee japan.
This committee was established on April 1985 under Japan Electronic
Industries Developement Association (JEIDA).
We 24 corporate members including US company, such as Symbolics, xerox,
Digital(DEC), univac, data general, and so on.
I have presented the existance of the committee at IJCAI'85 press conference
by myself.
As I am the translator of CLtL into japanese, gls knows me very well.
please refer him for my qualifications.
I have informed that you will organizing a committee X3J13 and a ISO one.
I got a message from several persons including Guy Steele, F.Kunze,
D. Bobrow when I met them at their room each.
They suggested me to attend the ANSI committee or ISO committee if possible.
I want to present the status of japan as to Common Lisp, and
I want to have a communication with you.
I have a plan to make a subset standard.
Private proposal was appeared at October meeting, and currently
working group for the subset is working with my private proposal.
I also have a proposal for japanese character representation.
It will conform with the AT&T UNIX standard for japanese character representation.
I already got a opinion of symbolics, xerox digital or other company.
TI asked their japanese representative to send my proposal to them.
The above two activities were already reported to several persons via UUCP network.
Fortunatelly, from April 6th 1986, My computer center was joined to CSNET.
So, communication with US persons will be much easier and will be much more firm.
Prof. Nakata of Tukuba university, who is the member of ISO SC22, asked me
to attend ISO lisp committee if the things will be going.
I wrtoe too much things on the first letter.
Please forgive me to send this suddden letter to you.
If you have an interest to me and my activity,
please send a mail to me. I will send a documents to you after I receive
your mail.
Thanks for reading this miss-spell-full letter.
Masayuki Ida
phD, Associate professor
Aoyama Gakuin University
Atsugi, Morinosato Aoyama 1-1
Kanagawa, Japan 243-01
tel: +81 462 48 1221 ext 4526
or home: +81 462 33 4004
csnet/arpanet ida%utokyo-relay.csnet@csnet-relay.arpa
uucp ...hplabs!kddlab!titcca!ccut!ida
...Shasta!nttlab!ccut!ida
--------------------
End forwarded message
∂21-Apr-86 0908 Bobrow.pa@Xerox.COM Re: Chairman
Received: from XEROX.COM by SU-AI.ARPA with TCP; 21 Apr 86 09:08:48 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 21 APR 86 09:03:16 PST
Date: 21 Apr 86 08:59 PST
From: Bobrow.pa@Xerox.COM
Subject: Re: Chairman
In-reply-to: Dick Gabriel <RPG@SU-AI.ARPA>'s message of 20 Apr 86 10:01
PST
To: RPG@SU-AI.ARPA
cc: cl-steering@SU-AI.ARPA
Message-ID: <860421-090316-1457@Xerox>
I support both nominations whole-heartedly.
Thany you Scott and Bob.
danny
∂21-Apr-86 1025 MATHIS@USC-ISIF.ARPA Re: Chairman
Received: from USC-ISIF.ARPA by SU-AI.ARPA with TCP; 21 Apr 86 10:25:16 PST
Date: 21 Apr 1986 10:27-PST
Sender: MATHIS@USC-ISIF.ARPA
Subject: Re: Chairman
From: MATHIS@USC-ISIF.ARPA
To: RPG@SU-AI.ARPA
Cc: cl-steering@SU-AI.ARPA
Message-ID: <[USC-ISIF.ARPA]21-Apr-86 10:27:19.MATHIS>
In-Reply-To: The message of 20 Apr 86 1001 PST from Dick Gabriel <RPG@SU-AI.ARPA>
I am willing to serve as Chairman. I don't understand rowing
very much, but I get the impression that the rowers do most of
the work and the coxswain has a role in coordination and timing.
That is somewhat of how I understand my chairmanship -- I am
depending on the real Lisp experts to do a lot of the work to
make sure we keep on the right course.
If we are moving to vote on something we need a balloting
process. My next message to cl-steering will be a balloting
message. To vote, reply to that message. We should also set a
normal timing for ballots -- say at least a week and closing on
Tuesday night (that would take care of end-of-week, weekend, and
first-of-week types to all have a chance to see the ballot
message and respond. A ballot message should not have general
discussion, only information about the vote.
-- Bob
∂21-Apr-86 1102 MATHIS@USC-ISIF.ARPA BALLOT - Mathis Chairman?
Received: from USC-ISIF.ARPA by SU-AI.ARPA with TCP; 21 Apr 86 11:01:32 PST
Date: 21 Apr 1986 11:02-PST
Sender: MATHIS@USC-ISIF.ARPA
Subject: BALLOT - Mathis Chairman?
From: MATHIS@USC-ISIF.ARPA
To: cl-steering@SU-AI.ARPA
Cc: Mathis@USC-ISIF.ARPA
Message-ID: <[USC-ISIF.ARPA]21-Apr-86 11:02:12.MATHIS>
Should Bob Mathis be elected Chairman of the Steering Committee?
Please reply by Tuesday 29 April.
(a sufficient answer should be just a "reply" to this message
which will show the subject and then just your yes or no. As the
issues get more complicated there may need to be additional text,
but we should try to keep the balloting process simple.)
∂21-Apr-86 1108 RPG Should Mathis ...
To: cl-steering@SU-AI.ARPA
Yes.
-rpg-
∂21-Apr-86 1151 FAHLMAN@C.CS.CMU.EDU BALLOT - Mathis Chairman?
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 21 Apr 86 11:51:19 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 21 Apr 86 14:53:53-EST
Date: Mon, 21 Apr 1986 14:53 EST
Message-ID: <FAHLMAN.12200661231.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: MATHIS@USC-ISIF.ARPA
Cc: cl-steering@SU-AI.ARPA
Subject: BALLOT - Mathis Chairman?
In-reply-to: Msg of 21 Apr 1986 14:02-EST from MATHIS at USC-ISIF.ARPA
(I don't think that technical committee members should vote on this, but
in case people feel they should...)
Yes.
-- Scott
∂21-Apr-86 1754 OHLANDER@USC-ISIB.ARPA Mathis as Chairman
Received: from USC-ISIB.ARPA by SU-AI.ARPA with TCP; 21 Apr 86 17:53:32 PST
Date: 21 Apr 1986 17:52-PST
Sender: OHLANDER@USC-ISIB.ARPA
Subject: Mathis as Chairman
From: OHLANDER@USC-ISIB.ARPA
To: cl-steering@SU-AI.ARPA
Message-ID: <[USC-ISIB.ARPA]21-Apr-86 17:52:30.OHLANDER>
I concur that Bob Mathis would be the appropriate chairman.
Ron Ohlander
∂21-Apr-86 1913 Bobrow.pa@Xerox.COM Re: BALLOT - Mathis Chairman?
Received: from XEROX.COM by SU-AI.ARPA with TCP; 21 Apr 86 19:13:16 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 21 APR 86 19:14:15 PST
Date: 21 Apr 86 19:13 PST
From: Bobrow.pa@Xerox.COM
Subject: Re: BALLOT - Mathis Chairman?
In-reply-to: MATHIS@USC-ISIF.ARPA's message of 21 Apr 86 11:02 PST
To: MATHIS@USC-ISIF.ARPA
cc: cl-steering@SU-AI.ARPA
Message-ID: <860421-191415-2221@Xerox>
yes
∂22-Apr-86 0540 MATHIS@USC-ISIF.ARPA EuLisp
Received: from USC-ISIF.ARPA by SU-AI.ARPA with TCP; 22 Apr 86 05:39:59 PST
Date: 22 Apr 1986 05:42-PST
Sender: MATHIS@USC-ISIF.ARPA
Subject: EuLisp
From: MATHIS@USC-ISIF.ARPA
To: cl-steering@SU-AI.ARPA
Cc: Mathis@USC-ISIF.ARPA
Message-ID: <[USC-ISIF.ARPA]22-Apr-86 05:42:20.MATHIS>
I had planned to go to the EuLisp meeting in Paris on May 5, but
it has just been changed to Erlangen, Germany, on May 2. So I
will not be going. I just talked to Jerome Chailloux. They
intend to finish their first draft at that meeting and distribute
it on the Common Lisp electronic mailing list. Their next
meeting will probably be June 2 in Bath England. I will try to
go to that one. (Just like everybody, I need 3-4 weeks planning
lead time.) Their August meeting will be in Boston at the same
time as the Lisp Conference. We should probably plan some
information on Common Lisp standardization activities for that
conference. What's appropriate?
-- Bob
∂22-Apr-86 0732 DLW@SCRC-STONY-BROOK.ARPA Lisp conference
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 22 Apr 86 07:31:43 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 469023; Tue 22-Apr-86 10:30:02-EST
Date: Tue, 22 Apr 86 10:30 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: Lisp conference
To: MATHIS@USC-ISIF.ARPA, cl-steering@SU-AI.ARPA
In-Reply-To: <[USC-ISIF.ARPA]22-Apr-86 05:42:20.MATHIS>
Message-ID: <860422103049.3.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: 22 Apr 1986 05:42-PST
From: MATHIS@USC-ISIF.ARPA
Their August meeting will be in Boston at the same
time as the Lisp Conference. We should probably plan some
information on Common Lisp standardization activities for that
conference. What's appropriate?
In my opinion, the most important thing would be an announcement to the
attendees of the current state of things. We should announce the
existence and member of the technical and steering committees, and give
a brief agenda for each of them. We should explain what's going on with
ANSI and ISO, and what's going on regarding the formal definition of the
standard. We should also clear the air by announcing the official state
of standardization of extensions, such as the error/condition system,
object-oriented programming, and window systems. (By "we" I'm not
necessarily including myself, since I'm not personally on the
committees, but that's not important.) Presumably the conference
chairman should figure out how to best fit this into the format of the
conference.
By the way, you might be interested to know that the program committee
for the conference accepted a paper entitled "Desiderata for the
standardization of Lisp", by 13 European authors, headed by Julian
Padgett of Bath and including Chailloux. It attempts to present the
situation up to now, present some conclusions about how to proceed, and
their present progress to date, of which there is little, as they
readily admit. One of their conclusions is that there should be several
levels of standard, each a proper subset of the one above. It's clear
that they are trying to live with Common Lisp rather than fight it; the
tone is pretty reasonable and I don't see any problems coming from this.
∂22-Apr-86 0745 FAHLMAN@C.CS.CMU.EDU Lisp conference
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 22 Apr 86 07:45:47 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 22 Apr 86 10:48:22-EST
Date: Tue, 22 Apr 1986 10:48 EST
Message-ID: <FAHLMAN.12200878681.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-steering@SU-AI.ARPA
Subject: Lisp conference
In-reply-to: Msg of Tue 22 Apr 86 10:30 EST from Daniel L. Weinreb <DLW at SCRC-QUABBIN.ARPA>
I think that Dan Weinreb's message covered the essential points of what
needs to happen at the Lisp Conference, except that I would add the need
for a question/answer session with as many members of the technical and
steering committees as we can conveniently round up. Perhaps the right
format is a 90 minute session with half an hour of status reports and an
hour of open discussion.
My guess is that this will be very heavily attended, so we'll need the
largest available room. I doubt that any slots are left on the official
program, so this may have to be an evening add-on of some sort. I
beleive that some of us are on the program committee for the meeting, so
maybe those people could make known our desire for a time slot of some
sort.
-- Scott
∂22-Apr-86 0841 FAHLMAN@C.CS.CMU.EDU EuLisp
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 22 Apr 86 08:41:24 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 22 Apr 86 11:43:52-EST
Date: Tue, 22 Apr 1986 11:43 EST
Message-ID: <FAHLMAN.12200888762.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: MATHIS@USC-ISIF.ARPA
Cc: cl-steering@SU-AI.ARPA
Subject: EuLisp
In-reply-to: Msg of 22 Apr 1986 08:42-EST from MATHIS at USC-ISIF.ARPA
I note that some cracks seem to be developing within the Eulisp group,
and that they are nearing the point where the differences in goals
between the formalists and the hackers will begin to manifest themselves
in major technical disagreements. It looks like the move of the May
meeting to Erlangen was the only way to keep Stoyan on board. It will
be interesting to see if the June meeting comes off, and whether they
are still working smoothly together by then.
With respect to Eulisp and the Eulisp people, I think that the following
points should be raised with them fairly soon. It is best to approach
this though Chailloux, as he seems to be more interested in Common Lisp
than the Padgett and Fitch.
1. We have told them this before, but we should reiterate our view that
it is necessary to standardize something reasonably close to the current
Common Lisp under ANSI and, if possible, under ISO. By "reasonably
close", I mean that we must recognize that many Common Lisp
implementations and a growing body of user code and training materials
exist already or are in preparation, so in the definition of the
standard we must not make any incompatible changes unless the benefits
very clearly outweigh the costs. In this process, we do not feel that
we are free to start from scratch and reconsider all of the old
decisions. We certainly do not view the current Common Lisp as perfect,
but it has attained the status of a de facto standard in the U.S. and
many other parts of the world, and orderly progress demands that we make
this standard explicit and official and that we clean up the current
ambiguities as best we can.
2. It is our intention to develop a cleaned-up language specification
for the full language, and submit this to ANSI and then to ISO as a
proposed standard for ANSI/ISO Common Lisp. We do not view this as
casting the Common Lisp spec in stone forever, nor do we wish to
preclude the emergence of an ISO standrd for some different Lisp or for
an official Common Lisp subset or set of "layers". But for all of us,
the first priority is developing a usable standard for the full
language, and we do not currently view a layered approach or a
definition using formal semantics as the quickest or best way to attain
that goal.
3. We recognize that some members of the Eulisp group want to develop a
"post-Common" Lisp that would be different in many ways from the
currently defined language. Others appear to want a mulitple-level
specification, with the most complex level corresponding closely to to
the current Common Lisp and with the lower levels being subsets. The
simplest levels may be definable by formal mathematical methods. We
respect these goals and wish you well, but we hope that such activities
will not preclude an ISO standard for something close to the current
Common Lisp with a specification that discusses only the full language.
4. If the Eulisp group or any individual members wish to contribute to
the standardization effort outlined in points 1 and 2 (even while
pursuing your own activities as discussed in point 3) we would welcome
such participation, either through the open discussions on the Common
Lisp mailing list, or perhaps by adding a Eulisp person to our technical
and/or steering committees. We would like to discuss this committee
membership if there is serious interest.
5. If you feel that you cannot subscribe to our goals and plans, we
understand, and wish you well. Even if we disagree on the best form for
a standard, we hope that the gorups can remain in close contact and can
learn from each other's efforts.
-- Scott
∂22-Apr-86 1335 Moon@SCRC-STONY-BROOK.ARPA EuLisp
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 22 Apr 86 13:17:29 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 469495; Tue 22-Apr-86 15:43:18-EST
Date: Tue, 22 Apr 86 15:42 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: EuLisp
To: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
cc: MATHIS@USC-ISIF.ARPA, cl-steering@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12200888762.BABYL@C.CS.CMU.EDU>
Message-ID: <860422154223.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Well said. I agree with you. (Oh, that's right, I'm not on the steering committee).
∂22-Apr-86 2134 FAHLMAN@C.CS.CMU.EDU Specification Document
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 22 Apr 86 21:14:50 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 23 Apr 86 00:17:26-EST
Date: Wed, 23 Apr 1986 00:17 EST
Message-ID: <FAHLMAN.12201025953.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-steering@SU-AI.ARPA
Subject: Specification Document
We need to keep moving on getting a document together, if indeed that is
going to be the central focus of our effort.
Several people on the technical committee have expressed a desire to get
a copy of the Lucid document so that we can all discuss what mixture of
materials we want to use. Dick, is it possible to send copies to
everyone on the technical committee? Presumably everyone has a copy of
CLtL, which is the other likely source of material.
It would certainly be simplest all around to develop a public-domain
document, but I see several problems with this. First, Bob Mathis says
that ANSI likes to copyright their standards documents. Second, Digital
Press might be more willing to grant ANSI permission to create a
derivitive work incorporating material from CLtL than to drop a lot of
material into the public domain. Third, once the work is in the public
domain, nobody has any control over it at all, and a confusing array of
mutant versions could appear.
Let me propose the following model to see if it sounds good to all of us
and, if so, whether we can sell it to ANSI, Digital Press, and Lucid's
hairy lawyers.
The standards document that we develop for Common Lisp would contain the
following copyright notice (language subject to tuning if we can get
some legal advice):
---------------------------------------------------------------------------
Copyright (c) 1986, 1987 American National Standards Institute
[[ Is that what ANSI stands for or did I guess wrong? ]]
Permission is hereby granted for any individual or organization to
reproduce the contents of this document without charge, in printed or
computer readable form, provided that the following conditions are
observed:
1. Every copy must include this copyright notice.
2. The text of this document must be reproduced in its entirety, without
any deletions or alterations.
3. Material may be added to the text of this document, but all such
material must be clearly marked as not being part of the original text.
---------------------------------------------------------------------------
Digital Press would grant permission to ANSI, in advance, to produce a
derivitive work incorporating portions of the text of CLtL, with the
understanding that the result would be published with the copyright
notice and permission statement listed above. The letter would make
clear that this permission in no way limits Digital Press's right to use
the original material themselves or to authorize the creation of new
editions or other derivitive works for their own use.
Lucid would agree to the same thing with regard to their manual.
Once these agreements are in place, I suggest that we copy the sources
to these documents to CMU. I am willing to coordinate the task of
producing a new document, given these sources, and to do most of the
necessary rewriting as decisions get made. (I will be looking for help
on specific chapters and issues, however.) The new document would
appear chapter by chapter in a directory that everyone in the Common
Lisp community could access. As I mentioned earlier, there would also
be a file listing all of the known differences between the new document
and CLtL and perhaps some other supporting docuemnts not part of the
standard.
If ANSI agrees to the "anyone can copy" provisions described above, I
have no major problem with developing this thing under the ANSI
copyright from the start. However, as of today we have no standing
within ANSI, and I'm not sure that it is appropriate for this document
to be "owned" by ANSI until it has been endorsed by X3J13 and accepted
by ANSI. There's the interesting question of who would own the document
if, for some reason, ANSI rejects it -- we would want to be in a
position to distribute the document and use it as an informal de facto
standard in that case.
Given that, perhaps the right move is to replace ANSI with "us" in the
above copyright notice and agreements, and to assign the copyright to
ANSI when and if they adopt the document as a standard. "Us" in this
case could be a non-profit corporation set up for the purpose -- The
Common Lisp Technical Committee, Inc. -- or it could be, say, the
chairman of the technical committee who would informally agree to hold
the copyright in trust for the whole group. The corporation is the
cleaner solution, but nobody answered my earlier query on what it would
take to form one, so I don't think any of us want to go through the
hassle.
Please let me know what you think of this plan. Perhaps Bob Mathis
could sound out ANSI on whether they would agree to something like this,
Steele could sound out Digital Press, and Gabriel could talk to Lucid's
lawyers about it. We should find out about the plan in which the thing
is copyrighted by ANSI from the start, and also about the plan in which
one of us holds the copyright until the thing is approved.
It would be very nice if we could get this all settled within a week or
two, so that we can start the real work.
-- Scott
∂23-Apr-86 0924 OHLANDER@USC-ISIB.ARPA Specification Document
Received: from USC-ISIB.ARPA by SU-AI.ARPA with TCP; 23 Apr 86 09:24:31 PST
Date: 23 Apr 1986 09:24-PST
Sender: OHLANDER@USC-ISIB.ARPA
Subject: Specification Document
From: OHLANDER@USC-ISIB.ARPA
To: Fahlman@C.CS.CMU.EDU
Cc: CL-Steering@SU-AI.ARPA
Message-ID: <[USC-ISIB.ARPA]23-Apr-86 09:24:51.OHLANDER>
Scott,
I think that your concern over a specification document is
well founded and something that should be resolved as soon as possible.
One concern that I have, however, in letting ANSI have control of the
copyright, is whether we can get changes made in a reasonable way when
we have to. It may be the case that they are perfectly willing to share
the document but that it takes great effort and excessive time to ever
get the document changed. I think that we should look into this
aspect of the matter. Perhaps Bob Mathis could enlighten us.
Ron
∂23-Apr-86 1451 Moon@SCRC-STONY-BROOK.ARPA Specification Document
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 23 Apr 86 14:51:43 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 470577; Wed 23-Apr-86 17:38:24-EST
Date: Wed, 23 Apr 86 17:37 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Specification Document
To: cl-steering@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12201025953.BABYL@C.CS.CMU.EDU>
Message-ID: <860423173738.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Perhaps I'm mistaken, but I was under the impression that X3 is not part of ANSI.
∂25-Apr-86 1024 gls@THINK-AQUINAS.ARPA Re: Chairman
Received: from AQUINAS.THINK.COM by SU-AI.ARPA with TCP; 25 Apr 86 10:24:27 PST
Received: from THINK-KATHERINE.ARPA by THINK-AQUINAS.ARPA via CHAOS with CHAOS-MAIL id 21405; Fri 25-Apr-86 13:28:47-EST
Date: Fri, 25 Apr 86 13:26 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Re: Chairman
To: MATHIS@USC-ISIF.ARPA, RPG@SU-AI.ARPA
cc: cl-steering@SU-AI.ARPA, gls@THINK-AQUINAS.ARPA
In-Reply-To: <[USC-ISIF.ARPA]21-Apr-86 10:27:19.MATHIS>
Message-ID: <860425132609.2.GLS@THINK-KATHERINE.ARPA>
Date: 21 Apr 1986 10:27-PST
From: MATHIS@USC-ISIF.ARPA
I am willing to serve as Chairman. I don't understand rowing
very much, but I get the impression that the rowers do most of
the work and the coxswain has a role in coordination and timing.
...
I used to row in my undergraduate days at Harvard. One thing to keep
in mind is that the only the coxswain can see where the boat is going;
everyone else faces backwards. The coxswain not only steers, but he
pounds the sides of the boat and yells a lot. He is also responsible
for providing lemons for the rowers to suck on.
--Guy
∂25-Apr-86 1028 gls@THINK-AQUINAS.ARPA BALLOT - Mathis Chairman?
Received: from AQUINAS.THINK.COM by SU-AI.ARPA with TCP; 25 Apr 86 10:27:04 PST
Received: from THINK-KATHERINE.ARPA by THINK-AQUINAS.ARPA via CHAOS with CHAOS-MAIL id 21407; Fri 25-Apr-86 13:30:53-EST
Date: Fri, 25 Apr 86 13:28 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: BALLOT - Mathis Chairman?
To: MATHIS@USC-ISIF.ARPA, cl-steering@SU-AI.ARPA
cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: <[USC-ISIF.ARPA]21-Apr-86 11:02:12.MATHIS>
Message-ID: <860425132820.3.GLS@THINK-KATHERINE.ARPA>
Yes.
[Perhaps we should first have a ballot on the subject of:
"Should Bob Mathis be in charge of the first ballot?"
but that way recursive madness lies. :-) Boy, am I in
a good mood today!]
--Guy
∂25-Apr-86 1038 gls@THINK-AQUINAS.ARPA EuLisp
Received: from AQUINAS.THINK.COM by SU-AI.ARPA with TCP; 25 Apr 86 10:37:49 PST
Received: from THINK-KATHERINE.ARPA by THINK-AQUINAS.ARPA via CHAOS with CHAOS-MAIL id 21413; Fri 25-Apr-86 13:42:04-EST
Date: Fri, 25 Apr 86 13:39 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: EuLisp
To: Fahlman@CMU-CS-C.ARPA, MATHIS@USC-ISIF.ARPA
cc: cl-steering@SU-AI.ARPA, gls@THINK-AQUINAS.ARPA
In-Reply-To: <FAHLMAN.12200888762.BABYL@C.CS.CMU.EDU>
Message-ID: <860425133932.7.GLS@THINK-KATHERINE.ARPA>
Well said. I agree with you. (I am on the steering committee, and I'm
not above swiping Moon's material.)
--Guy
∂25-Apr-86 1315 FAHLMAN@C.CS.CMU.EDU Chairman
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 25 Apr 86 13:15:29 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 25 Apr 86 15:59:40-EST
Date: Fri, 25 Apr 1986 15:59 EST
Message-ID: <FAHLMAN.12201721776.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-steering@SU-AI.ARPA
Subject: Chairman
In-reply-to: Msg of 25 Apr 1986 13:26-EST from Guy Steele <gls at THINK-AQUINAS.ARPA>
I never rowed in my undergraduate days, so the only image I have of the
role of the coxswain is the guy beating the big drum on the galley in
Ben Hur (and his assistants with the whips and electric cattle prods).
Probably this group is so self-motivated that we won't need the whips
very often...
Ramming Speed!
-- Scott
∂03-May-86 1529 squires@ipto.ARPA Japanese representative
Received: from IPTO.ARPA by SU-AI.ARPA with TCP; 3 May 86 15:28:52 PDT
Received: by ipto.ARPA (4.12/4.7)
id AA05936; Sat, 3 May 86 18:29:52 edt
Date: Sat 3 May 86 18:29:46-EDT
From: Stephen Squires <SQUIRES@IPTO.ARPA>
Subject: Japanese representative
To: cl-steering@SU-AI.ARPA
Message-Id: <VAX-MM(187)+TOPSLIB(118) 3-May-86 18:29:46.IPTO.ARPA>
The following message contains a confirmation for Kouichi's recommendation
for having Ida be the Japanesse representative with his CS-Net address:
---------------
Received: from isi-vaxa.ARPA by ipto.ARPA (4.12/4.7)
id AA05718; Sat, 3 May 86 15:08:42 edt
Received: by isi-vaxa.ARPA (4.12/4.7)
id AA19486; Sat, 3 May 86 12:08:04 pdt
Message-Id: <8605031908.AA19486@isi-vaxa.ARPA>
Date: 3 May 1986 1208-PDT (Saturday)
To: squires@IPTO.ARPA
From: balzer@ISI-VAXA.ARPA
Subject: Japaneese representative on Lisp Committee
-------------- Begin Forwarded Message --------------
TO: balzer@ISI-VAXA
FROM: ihnp4!kddlab!k2@srava.sra.junet (Kouichi Kishida)
SUBJECT: Lisp Committee
CC: k2@seismo.CSS.GOV
RECEIVED: 5/03/86 11:53:35
SENT: 5/01/86 17:54:09
CC: k2@seismo.CSS.GOV
TO: BALZER@ISI-VAXA.ARPA
MESSAGE-ID: <8605020054.AA09039@srava.sra.junet>
FROM: ihnp4!kddlab!k2@srava.sra.junet (Kouichi Kishida)
RECEIVED: by srava.sra.junet (4.13/4.9J/3.1)
RECEIVED: by titan.junet (4.12/6.0Junet)
RECEIVED: by kddlabs.junet (4.12/4.7)
RECEIVED: by ihnp4.ATT.COM id AA00436; 2 May 86 10:39:36 CDT (Fri)
RECEIVED: from ihnp4.UUCP by seismo.CSS.GOV with UUCP; Sat, 3 May 86 07:15:18 EDT
RETURN-PATH: <ihnp4!kddlab!titcca!srava!k2>
RECEIVED: from seismo.CSS.GOV (css-ring-gw.arpa) by isi-vaxa.ARPA (4.12/4.7)
RETURN-PATH: <ihnp4!kddlab!titcca!srava!k2@seismo.CSS.GOV> id AA18147; Sat, 3 May 86 04:35:03 pdt id AA04713; Fri, 2 May 86 12:01:37-1500 id AA04710; Fri, 2 May 86 12:01:31-1500 id AA24910; Fri, 2 May 86 10:47:51 jst id AA09039; Fri, 2 May 86 09:54:09 jst
This mail is just a reconfirmation of my phone message.
The person I recommend for Lisp Standardization Committee is:
Prof. Masayuki Ida
Computer Science Lab.
Aoyama Gakuin Univ.
1626 Ono, Atugi City, Kanagawa 234-01 Japan
TEL 0462-48-1221 ex 4526
CS-Net Address is : ida%utokyo-relay.csnet@csnet-relay.arpa
Regards,
Kouichi
-------
-------
∂03-May-86 1903 FAHLMAN@C.CS.CMU.EDU Japanese representative and other topics
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 3 May 86 19:03:22 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 3 May 86 22:04:19-EDT
Date: Sat, 3 May 1986 22:04 EDT
Message-ID: <FAHLMAN.12203874399.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-steering@SU-AI.ARPA
Subject: Japanese representative and other topics
In-reply-to: Msg of 3 May 1986 18:29-EDT from Stephen Squires <SQUIRES at IPTO.ARPA>
I had hoped to hear from a few more of the Japanese biggies before we
did anything, but we shouldn't let this hang for too long. Maybe we
should go along and propose to Ida the structure that I suggested
earlier (the JEIDA committee gets to pick a delegate, which will almost
certainly be Ida) and if it sounds OK to him we'll announce the plan
on Common Lisp, to which many other Japanese are now listening.
Maybe we should also send the statement I proposed earlier to Chailloux
and/or to the Eulisp mailing list? People receiving the Eulisp
transmissions have recently seen a reiteration of their view (at least,
Fitch and Stoyan's view) that Common Lisp, as it is presently
constituted, ought not to be standardized. They've got this idea that a
Lisp standard must be some sort of ideal of perfection that industry
ought then to try to live up to, while our view is (I think) that we've
already got a de facto standard, for better or worse, and we may as well
try to formalize it and clean it up a bit in the process.
My earlier proposal on copyrights and such seems not to have led to much
action. Until we find out if Digital Press and Lucid will grant us the
rights I described and if ANSI will agree to the "anyone can use it"
permission, we're effectively dead in the water. I believe that Mathis
should get an answer from ANSI on this, Steele from Digital Press, and
Gabriel from Lucid. Are there problems that need to be resolved before
this can be settled?
As I said earlier, I'm pretty well buried with work through mid-May, but
I expect to make quick progress in resolving a lot of technical issues
after that. If necessary, we can try to settle various issues and put
the decisions in a list, but I'd sure rather have an emerging document
at the center of this effort. Sometime soon, I'll try to come up with a
statement of principles about much change we think is desirable in this
process.
I guess the Technical Committee election is over, and I am your new
chairman. Thanks for the vote of confidence. I'll try to keep up a
steady beat on the drum.
-- Scott
∂06-May-86 1052 MATHIS@USC-ISIF.ARPA Lisp Standardization
Received: from USC-ISIF.ARPA by SU-AI.ARPA with TCP; 6 May 86 10:51:56 PDT
Date: 6 May 1986 10:52-PDT
Sender: MATHIS@USC-ISIF.ARPA
Subject: Lisp Standardization
From: MATHIS@USC-ISIF.ARPA
To: CL-STEERING@SU-AI.ARPA
Message-ID: <[USC-ISIF.ARPA] 6-May-86 10:52:25.MATHIS>
I have sent the following to other people who have expressed an
interest in the standardization process. I wanted all of you to
get it too, because it is too late to back out now.
This message is to confirm your net address and continuing
interest in the ANSI/X3J13 and ISO/TC97/SC22 standardization of
Lisp. The general mailing list "Common-Lisp at SU-AI" will
continue to receive information, this special list is only for
those with an active interest in the standardization process
itself.
-- Bob Mathis
∂06-May-86 1151 MATHIS@USC-ISIF.ARPA X3J13 Hull Pounding
Received: from USC-ISIF.ARPA by SU-AI.ARPA with TCP; 6 May 86 11:51:32 PDT
Date: 6 May 1986 11:53-PDT
Sender: MATHIS@USC-ISIF.ARPA
Subject: X3J13 Hull Pounding
From: MATHIS@USC-ISIF.ARPA
To: cl-steering@SU-AI.ARPA
Cc: Mathis@USC-ISIF.ARPA
Message-ID: <[USC-ISIF.ARPA] 6-May-86 11:53:21.MATHIS>
Thank you for my selection as the Chairman of the Steering
Committee.
X3J13 has been approved. There will be no election of Chairman
for that until the end of the year. At the moment, I am the
Convenor of the first meetings. In that role I can effectively
direct the initial work. To that end I am hereby appointing what
we have called a Steering Committee as a Steering Committee to
help in guiding the work of X3J13 and I am appointing what we
have called a Technical Committee as a Technical Committee to
prepare initial items for discussion and potentially a draft of
the proposed standard.
You are no longer a self selected gang, but a legitimate
subcommittee under an approved standrards committee.
On the copyright question -- I have talked to DEC people and sent
some other information to Lucid. ANSI has to make money on the
publication of some of its standards, so the very broad
suggestion of Scott's will probably not work. Questions arise
with respect to commercial publication (PH, AW, Wiley, et al),
manufacturers' manuals (goldhill's distribution of the DEC book,
etc), derived manuals (possibly Lucid's), and on-line
documentation. ANSI would probably not like the first, but would
probably go with the last three. This is something where the
ANSI, DEC and Lucid lawyers will have to work something out with
our guidance.
On the Lucid manual as a starting point. I always assume the
rest of you are better informed than I am, so this is just a
personal request for a copy. It also seems likely that other
companies have their own manuals which may be very relevant in
places. We should probably make a general request for copies of
those manuals and establish a physical library at either CMU or
ISI for reference by the drafters.
Lisp Conference in Boston -- I would suggest a SHORT time period
during the regular session to give a status report (both
X3J13/ISO and technical) and then an evening (or other out of the
normal schedule) session for those specifically interested in
details. We should definitely take the opportunity to meet
ourselves.
Validation test suites -- we need to remind people of this again.
Standing agenda -- I plan to develop a standing agenda for the
Steering Committee that we can also use as a kind of status and
progress report. After reviewing it with you, I will put out
another general message about how X3J13 will be organized and
work.
-- Bob Mathis
∂07-May-86 0710 FAHLMAN@C.CS.CMU.EDU Addition to mailing list
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 7 May 86 07:09:56 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 7 May 86 10:10:48-EDT
Date: Wed, 7 May 1986 10:10 EDT
Message-ID: <FAHLMAN.12204793064.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-steering@SU-AI.ARPA
Cc: ram@C.CS.CMU.EDU
Subject: Addition to mailing list
If there are no objections, I would like to have Rob Maclachlan of CMU
(RAM@C.CS.CMU.EDU) added to the technical and, by transitivity, the
steering committee mailing lists as a non-voting observer. Rob will be
helping me to organize the technical side of things and keep track of
decisions, so it is convenient for me if he is able to follow closely
what we are doing. Rob will of course continue to particpate in the
design discussions on the normal Common Lisp mailing list, where his
contributions have been extremely valuable.
-- Scott
∂07-May-86 1200 OHLANDER@USC-ISIB.ARPA Re: Addition to mailing list
Received: from USC-ISIB.ARPA by SU-AI.ARPA with TCP; 7 May 86 12:00:36 PDT
Date: 7 May 1986 11:57-PDT
Sender: OHLANDER@USC-ISIB.ARPA
Subject: Re: Addition to mailing list
From: OHLANDER@USC-ISIB.ARPA
To: Fahlman@C.CS.CMU.EDU
Cc: cl-steering@SU-AI.ARPA, ram@C.CS.CMU.EDU
Message-ID: <[USC-ISIB.ARPA] 7-May-86 11:57:09.OHLANDER>
In-Reply-To: <FAHLMAN.12204793064.BABYL@C.CS.CMU.EDU>
No objections.
Ron
∂08-May-86 2338 FAHLMAN@C.CS.CMU.EDU Copyrights
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 8 May 86 23:38:49 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 9 May 86 02:39:44-EDT
Date: Fri, 9 May 1986 02:39 EDT
Message-ID: <FAHLMAN.12205235256.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-steering@SU-AI.ARPA
Subject: Copyrights
This business of copyrights is a make-or-break issue. We've got to get
this settled to everyone's satisfaction, and we can't wait around for
lawyers to do it at their own usual pace or we'll lose at least a year.
We need to get an agreement in principle between our group, ANSI, and at
least one of Lucid or Digital Press before we can start serious work on
the new specification document.
Bob Mathis says that ANSI needs to make some money on the publication of
the standards document. OK. An interesting question is how much money
they need to make. I have no objection to ANSI making some money on the
document. Presumably they will put the money to good use. But if
ANSI's need to make money from this document means that companies cannot
quickly and easily get permission to duplicate the document, that nobody
will know for sure what the rules are for online use, and that students
have to pay some arbitrarily high price for a copy, then I for one am
not going to particpate in producing such a document. There are so many
possible mistakes I haven't made yet that I'm not going to waste time
making the old ones over again. We've got to have some clear
understandings about these issues before we begin.
I wonder if the following would fly: the manual carries the same
copyright notice as before, with blanket permission for verbatim
copying, but the notice is changed to say that anyone making a hardcopy
must pay ANSI, say, $2. If a publisher or manufacturer prints up a ton
of the manuals, ANSI gets a decent royalty; if a university prints up
100 copies, they can either be honest and pay up or they can break the
law. ANSI would print up some official copies of their own, for which
they could charge whatever they usually do.
There would be no charge for online copies, since it is impossible to do
the accounting. If anyone cares, the charge could apply to copies
distributed on tape, floppy, or optical disk. Lucid and Digital Press
would of course retain full, free, and unrestricted rights to their own
curent documents, but if they want to make copies of the final ANSI
document, they would have to pay like anyone else.
ANSI would make out just fine on that, I think, and the $2 charge
wouldn't bother anyone too much. We would have the nearly-free right to
reproduce the document that we want.
I suppose that if ANSI doesn't want to put all of this into the
document, I would settle for a written agreement between them and us
that they would grant such a licesne to anyone within a month of
receiving the request, and that the royalty would not be more than $2
per copy. And if they break this agreement, or if this document is not
adopted as an ANSI standard, it becomes public-domain.
Bob, can you get a reading on whether ANSI would agree to something like
this? We can lawyerize it all later.
-- Scott
∂09-May-86 1130 OHLANDER@USC-ISIB.ARPA Re: Copyrights
Received: from USC-ISIB.ARPA by SU-AI.ARPA with TCP; 9 May 86 11:27:46 PDT
Date: 9 May 1986 11:10-PDT
Sender: OHLANDER@USC-ISIB.ARPA
Subject: Re: Copyrights
From: OHLANDER@USC-ISIB.ARPA
To: Fahlman@C.CS.CMU.EDU
Cc: cl-steering@SU-AI.ARPA
Message-ID: <[USC-ISIB.ARPA] 9-May-86 11:10:44.OHLANDER>
In-Reply-To: <FAHLMAN.12205235256.BABYL@C.CS.CMU.EDU>
Scott,
Your points are well taken. I have raised the issue
before and I'll raise it again that we do not want to place
ourselves in the same bind vis-a-vis ANSI that we have had with
Digital. I think that we have to give some rights to ANSI but we
had damn well better make sure that we have ultimate rights to
what we need. We must, for example, have the rights to the
Common Lisp Specification. We should also have the rights (as
you have already pointed out) to provide online manuals and
documents to those who need them for implementation. I think the
issue should be what rights we allow them rather than what rights
they want to give them.
Ron
∂09-May-86 1917 FAHLMAN@C.CS.CMU.EDU Copyrights
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 9 May 86 19:17:44 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 9 May 86 22:18:30-EDT
Date: Fri, 9 May 1986 22:18 EDT
Message-ID: <FAHLMAN.12205449845.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: OHLANDER@USC-ISIB.ARPA
Cc: cl-steering@SU-AI.ARPA
Subject: Copyrights
In-reply-to: Msg of 9 May 1986 14:10-EDT from OHLANDER at USC-ISIB.ARPA
Ron,
I'm not sure that I understand all of the points in your recent message.
You say that
we had damn well better make sure that we have ultimate rights to
what we need. We must, for example, have the rights to the
Common Lisp Specification.
I'm not sure what rights you are talking about here, and how you want to
define "we". If we produce a document that is both spec and manual, and
if it is accepted as an ANSI standard, I just want to be sure that the
manual is readily available to all who need to use it in various ways.
We also want to be sure that there is some mechanism for producing
revised standards in the future, based on the text of the original
standard, but that would fall out of the normal ANSI process, I think.
I'm willing to let the ANSI process handle any future revisions, and
feel no great urge to keep the process in the hands of the current cast
of characters. I personally plan to get out of the Common Lisp game
once the first round of ANSI/ISO standardization is complete.
-- Scott
∂13-May-86 0143 OHLANDER@USC-ISIB.ARPA Re: Copyrights
Received: from USC-ISIB.ARPA by SU-AI.ARPA with TCP; 13 May 86 01:43:33 PDT
Date: 12 May 1986 17:32-PDT
Sender: OHLANDER@USC-ISIB.ARPA
Subject: Re: Copyrights
From: OHLANDER@USC-ISIB.ARPA
To: Fahlman@C.CS.CMU.EDU
Cc: cl-steering@SU-AI.ARPA
Message-ID: <[USC-ISIB.ARPA]12-May-86 17:32:59.OHLANDER>
In-Reply-To: <FAHLMAN.12205449845.BABYL@C.CS.CMU.EDU>
Scott,
My concern is that we don't just abrogate all rights to ANSI. We may
find ourselves in disagreement at some future time. In order to protect the
Common Lisp community, we should have some recourse to always go back to some
original document to make things the way that the Common Lisp community feels
that they should be. This would require, probably, either copyrighting the
Common Lisp specification under a representative organization of the Common
Lisp community or putting the specification in the Public Domain. If we
copyright the spec, we could then grant exclusive rights to ANSI to develop a
standard. I realize that this brings up that old problem of how we organize
such a group, but we may really have to face coming to grips with that issue.
I will talk to some people who have founded nonprofit organizations to see
what is involved. In the meantime, we should press on with getting some
agreement from DEC that we can make a derivative work of the Common Lisp
Specification for an ANSI standard.
Ron
∂13-May-86 0814 FAHLMAN@C.CS.CMU.EDU Copyrights
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 13 May 86 08:14:29 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 13 May 86 11:15:29-EDT
Date: Tue, 13 May 1986 11:15 EDT
Message-ID: <FAHLMAN.12206377717.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: OHLANDER@USC-ISIB.ARPA
Cc: cl-steering@SU-AI.ARPA
Subject: Copyrights
In-reply-to: Msg of 12 May 1986 20:32-EDT from OHLANDER at USC-ISIB.ARPA
I'm quite happy to work with a document in the public domain or one that
is copyrighted by one of us in trust for the group until we decide
what rights to turn over to ANSI et al. Even better is to set up a
formal organization (non-profit corporation, I guess) that consists of
the members of these committees to hold the copyrights, but someone else
has to carry the ball on setting up the legalities of that. This isn't
the problem we discussed earlier of how to organize the whole community
-- I think at this point we could get away with incorporating just the
committees that were selected (indirectly) by the whole community.
We need to get a clear reading from ANSI on what will happen if we bring
them a document that is public domain or copyrighted by someone else and
tell them, as the technical comittee, that this docuemnt is what we
think the Common Lisp standard should be. As I said before, I don't
have nay problem with them making some money selling copies and/or
collecting royalties, but ownership and total control of the text is
another matter. Whether we can come up with a sufficient set of written
agreements to make us feel good about turning ownership over to ANSI is
a complicated question.
It looks like getting this manual stuff straightened out is going to
take longer than I had hoped. As far as I know, most of us haven't even
seen the Lucid manual yet. I guess I'll get to work trying to organize
the issues into a set of items that we can decide, record, and stick
into the text later. More work, but everyone must be wondering why this
is taking so long, so we'd better start making some visible progress.
-- Scott
∂13-May-86 1109 FAHLMAN@C.CS.CMU.EDU Addition to mailing list
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 13 May 86 11:07:21 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 13 May 86 14:08:04-EDT
Date: Tue, 13 May 1986 14:07 EDT
Message-ID: <FAHLMAN.12206409134.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Cl-steering@SU-AI.ARPA
Subject: Addition to mailing list
In-reply-to: Msg of 8 May 1986 07:40-EDT from Martin <GRISS%HP-THOR at hplabs.ARPA>
There seem to ahve been no objections to adding RAM@C.CS.CMU.EDU to the
list as a non-voting observer. Dick, please make this change when you
get a chance.
I have no objection to other people
adding their assistants to the list as well, as long as the number
doesn't get out of hand. However, I would like to know specifically, by
name, everyone is receiving this mail and not have a lot of uncontrolled
indirection going on. We may have some sensitive issues to discuss.
-- Scott
∂13-May-86 1439 MATHIS@USC-ISIF.ARPA copyrights
Received: from USC-ISIF.ARPA by SU-AI.ARPA with TCP; 13 May 86 14:39:33 PDT
Date: 13 May 1986 12:41-PDT
Sender: MATHIS@USC-ISIF.ARPA
Subject: copyrights
Subject: [MATHIS@USC-ISIF.ARPA: copyrights]
From: MATHIS@USC-ISIF.ARPA
To: cl-steering@SU-AI.ARPA
Message-ID: <[USC-ISIF.ARPA]13-May-86 12:41:53.MATHIS>
Sorry this didn't go out because of my typing mistake. In my
opinion, we do not have to form a corporation just to hold the
copyright. For the moment we can begin work on a new document
and we own it until its copyright is assigned; if ANSI doesn't
accept what we have done, they have no right to withhold it from
publication. -- Bob
Begin forwarded message
Received: By USC-ISIF.ARPA via direct-append with Hermes; 9 May 86 14:03:22-PDT
Date: 9 May 1986 14:03-PDT
From: MATHIS@USC-ISIF.ARPA
To: cl←steering@SU-AI.ARPA
Cc: Mathis@USC-ISIF.ARPA
Subject: copyrights
Message-ID: <[USC-ISIF.ARPA] 9-May-86 14:03:19.MATHIS>
Sender: MATHIS@USC-ISIF.ARPA
Scott, et al,
I will take on the direct negotiation with ANSI on this point.
Scott's point about a prearranged royalty is a good fall back
position. The main thing to ANSI seems to be recovering the
basic cost of publication (not so much a concern for profits).
When we did Ada, DoD provided ANSI some copies that were to be
given to other national standards bodies. A similar idea here
might take some of the financial pressure off. It may also be
possible to arrange some other publication mechanism.
I understand Scott's point about not wanting to make the same
mistakes over again.
About timing; this is going to take a few months. There is no
problem with our working to make a derived work from the Steele
book and including whatever from the Lucid manual that may be
appropriate (both seem willing to let us start from their current
works if they have some rights to use the result). We have not
at this point made any commitment to ANSI or X3 to give them the
result of our work. All these things have to be negotiated.
I talked to some ANSI people earlier this week. They keep
reminding me that I never do anything quite the usual way; but I
remind them that I've had enough of that same old stuff. Anyway
they think there is something that can be worked out. The next
couple of weeks are bad ones for them, because of another large
meeting in the US. I will try to arrange a time when I can meet
with them and work things out face-to-face.
So far I have not seen any message on this topic which disagrees
with my philosophy or approach. If any of you think there are
other points to consider or options to be explored, PLEASE LET ME
KNOW.
Bob
--------------------
End forwarded message
∂13-May-86 1742 FAHLMAN@C.CS.CMU.EDU copyrights
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 13 May 86 17:41:54 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 13 May 86 20:42:56-EDT
Date: Tue, 13 May 1986 20:42 EDT
Message-ID: <FAHLMAN.12206481022.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: MATHIS@USC-ISIF.ARPA
Cc: cl-steering@SU-AI.ARPA
Subject: copyrights
In-reply-to: Msg of 13 May 1986 15:41-EDT from MATHIS at USC-ISIF.ARPA
I've got no philosphical differences with what Bob suggests, but I do
have a legal quibble:
As I understand the copyright law, we can't just "own the new document
until the copyright is assigned" unless we prevent members of the
community from getting copies of the new work. If we distribute the
draft specification widely without some sort of copyright notice on it,
that puts the text in the public domain. That is irreversible. ANSI
could later add a preface of some sort and copyright THAT, but anyone
would have the right to distribute the text with whatever changes they
feel like putting in.
That might not be so bad. Anyone wanting a definitive version with no
possibility of changes would have to come to ANSI or to us, depending on
who they trust. So ANSI might end up selling as many copies this way as
any other. And the rest of us could just forget about lawyers. It
might create some confusion to have mutant versions floating around, but
we could get the word out that only copies that are certified by ANSI
are to be treated as definitive. And it would minimize the amount of
lawyering needed. If ANSI and DEC or Lucid were willing to go along,
this is the route I'd prefer. It's hard to imagine DEC agreeing to
allow a derivitive work in the public domain; I'm not sure about Lucid.
If we don't want to go public-domain, either we keep the new manual out
of general circulation -- impossible -- or we have to put a copyright
notice on it. I think that means an individual or corporation ahs to be
named as the legal entity owning the copyright. So we have to either
form an organization or name one of us to "own" the manual until we turn
some of the rights over to ANSI. And we have to get permission from DEC
or Lucid to use their text in the way we specify. We can't start work
modifying their sources until we have that permission.
If I'm wrong about the legailities here, PLEASE LET ME KNOW.
-- Scott
∂13-May-86 2220 JMC copyright holder
To: cl-steering@SU-AI.ARPA
I think the organization that holds the copyright can be entirely informal,
i.e. the notice can be Copyright Common Lisp Steering Committee.
It can assign the copyright later. A lawyer won't like it, because
he'll ask, "What if the members fall out?". In so far as there is
confidence that people will continue to get along, this will work.
Legally it will be a partnership, and it would be best if the
organization as such never received any money.
∂14-May-86 0621 FAHLMAN@C.CS.CMU.EDU copyright holder
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 14 May 86 06:21:26 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 14 May 86 09:22:33-EDT
Date: Wed, 14 May 1986 09:22 EDT
Message-ID: <FAHLMAN.12206619304.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: John McCarthy <JMC@SU-AI.ARPA>
Cc: cl-steering@SU-AI.ARPA
Subject: copyright holder
In-reply-to: Msg of 14 May 1986 01:20-EDT from John McCarthy <JMC at SU-AI.ARPA>
If copyrighting this document under "Common Lisp Steering Committee" (or
"Technical Committee" or both, whatever we decide is best) is legal it
could save us all a lot of hassle. We'd want to do something more
formal before we turn it over to someone for approval or publication,
but this could allow us to get started. The biggest remaining question
is whether Lucid and/or Digital Press will agree to turn over rights to
create a derivitive work to such a group.
-- Scott
∂14-May-86 0742 MATHIS@USC-ISIF.ARPA copyright holder
Received: from USC-ISIF.ARPA by SU-AI.ARPA with TCP; 14 May 86 07:42:43 PDT
Date: 14 May 1986 07:44-PDT
Sender: MATHIS@USC-ISIF.ARPA
Subject: copyright holder
From: MATHIS@USC-ISIF.ARPA
To: cl-steering@SU-AI.ARPA
Cc: Mathis@USC-ISIF.ARPA
Message-ID: <[USC-ISIF.ARPA]14-May-86 07:44:12.MATHIS>
One of the problems in standards work is liability. As an
informal partnership we can certainly copyright the various
working documents; but we should be clear that this is only a
technical proposal, which should keep us out of legal problems
until we get very close to the standardization (by which time
this will all have to be resolved).
Two recent situations point up potential difficulties. In one a
manufacturer of steam pressure gauges went out of business
because of a change in standards for such gauges by the Amer Soc
of Mech Eng; they sued and won. In another situation a life
insurance company threatened to sue members of the COBOL
Committee over changes they were proposing which might cost users
of the standard; they hasn't really happened (yet). I don't
think we are in any danger if we continue to treat our work at
this stage as a technical proposal. By the time we get to the
voting phases of the standards process, we will have all these
issues resolved.
-- Bob
∂14-May-86 0923 RPG Gentlemen,
To: CL-steering@SU-AI.ARPA
Here is the list of addresses to which the CL-Steering address forwards.
Please note the mailing list at Symbolics. I presume this includes exactly
Moon and Weinreb. #msg.msg[jnk,jmc] is a private mail file of McCarthy's.
I have deleted from this list, for the purposes of this message, the
archiving entry at SAIL.
rpg,
gls%GODOT.THINK.COM,
#msg.msg[jnk,jmc],
squires@IPTO.ARPA,
Mathis@USC-ISIF.ARPA,
ohlander@USC-ISIE.ARPA,
fahlman@C.CS.CMU.EDU,
bobrow.pa@XEROX.COM,
CL-Steering-from-SU-AI@SCRC-STONY-BROOK.ARPA,
alan@AI.AI.MIT.EDU,
jar@MC.LCS.MIT.EDU,
griss@HPLABS.ARPA,
RAM@C.CS.CMU.EDU
∂14-May-86 1029 DLW@SAPSUCKER.SCRC.Symbolics.COM Gentlemen,
Received: from [192.10.41.223] by SU-AI.ARPA with TCP; 14 May 86 10:29:31 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 19120; Wed 14-May-86 13:19:17 EDT
Date: Wed, 14 May 86 13:23 EDT
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: Gentlemen,
To: RPG@SU-AI.ARPA, CL-steering@SU-AI.ARPA
In-Reply-To: The message of 14 May 86 12:23 EDT from Dick Gabriel <RPG@SU-AI.ARPA>
Message-ID: <860514132300.4.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: 14 May 86 0923 PDT
From: Dick Gabriel <RPG@SU-AI.ARPA>
Please note the mailing list at Symbolics. I presume this includes exactly
Moon and Weinreb.
That's right.
∂15-May-86 1931 MATHIS@USC-ISIF.ARPA iso work on Lisp
Received: from USC-ISIF.ARPA by SU-AI.ARPA with TCP; 15 May 86 19:31:34 PDT
Date: 15 May 1986 19:32-PDT
Sender: MATHIS@USC-ISIF.ARPA
Subject: iso work on Lisp
Subject: [MATHIS@USC-ISIF.ARPA: Text of ISO NWI Proposal 18 February...]
Subject: [mcvax!inria!queinnec@seismo.CSS.GOV (Christian Queinnec)]
From: MATHIS@USC-ISIF.ARPA
To: cl-steering@SU-AI.ARPA
Message-ID: <[USC-ISIF.ARPA]15-May-86 19:32:36.MATHIS>
I just received the suggestions from Queinnec (who is chairman of
a french standards group) and don't really have a reaction yet.
I wanted you to see this as soon as possible. For comparison, I
am also forwarding the ISO NWI (New Work Item) proposal I drafted
and which has successfully passed through the US voting process.
-- Bob
Begin forwarded messages
Received: By USC-ISIF.ARPA via direct-append with Hermes; 22 Feb 86 08:39:58-PST
Date: 22 Feb 1986 08:39-PST
From: MATHIS@USC-ISIF.ARPA
To: Mathis@USC-ISIF.ARPA
Subject: Text of ISO NWI Proposal 18 February 1986
Message-ID: <[USC-ISIF.ARPA]22-Feb-86 08:39:57.MATHIS>
Sender: MATHIS@USC-ISIF.ARPA
1 Title
Information Processing Systems - Languages - Common Lisp
2 Scope
Development of an ISO standard for Common Lisp including its
syntax and semantics beginning from the proposed base document:
Common Lisp: The Language by Guy Steele Jr., Digital Press,
Burlington, MA, 1984.
The scope of the proposed standard language is essentially the
same as the scope Common Lisp as described in the Steele book;
i.e., the basic features and forms which should be supplied and
the extension mechanisms (functions, macros, and special forms)
which can be used to provide additional capabilities. There has
also been considerable work in Europe on the definition of
EU←LISP and in the US on the implementation of Common Lisp which
must also be considered.
The intent is to describe a programming language which can be
used in a number of different environments. Because of the
nature of the language and its implementations, the distinctions
between implemented language features, predefined system
functionality, and user defined supplementary capabilities are
not the same as in other languages; but there will still be some
issues to resolve about the size of the language, possible
subsets and supersets, and implementors' options.
3 Existing Documents
Common Lisp: The Language by Guy Steele Jr., Digital Press,
Burlington, MA, 1984; list of errata and issues being prepared by
Guy Steele; and also the EU←LISP specifications currently being
developed.
4 Liaison Organizations
The Common Lisp Community, the EU←LISP working Group, and the
various professional societies oriented toward artificial
intelligence programming languages.
5 Programme of Work
The first meeting of an ISO Working Group on Common Lisp should
take place during Winter 1987. Since there is already a well
accepted base document and the Common Lisp Community has already
begun considering issues and revisions, a Draft Proposal should
be ready by January 1988 for SC balloting.
6 Other Comments / Purpose and Justification
Lisp is the second oldest programming language still in current
use (after Fortran). Lisp has traditionally been the language
used for most Artificial Intelligence programming, and is now
becoming popular for non-AI tasks as well. Throughout its early
history, Lisp was the subject of much experimentation; this has
greatly improved the Lisp language, but has also led to a
proliferation of incompatible dialects. This lack of
standardization has impeded the acceptance of Lisp in industry.
In 1981, with the encouragement of DARPA, an effort was begun by
a number of researchers at several organizations to define a
commonly acceptable version of Lisp. The language specification
was written by members of this informal group, after extensive
discussions on the ARPAnet. The resulting book, Common Lisp: The
Language by Guy Steele Jr., has received world wide acceptance.
MACLISP, ZETALISP, SCHEME, INTERLISP, SPICE LISP, S-1 LISP, NIL
(New Implementation LISP), "Standard" LISP, and Portable
"Standard" LISP have all been considered in the design of Common
Lisp; and the most useful features of each were incorporated.
Common Lisp, as described in the Steele book, has now become a de
facto standard within the US, and there is great interest in this
language elsewhere. The following manufacturers currently offer
Common Lisp or have announced plans to offer Common Lisp as a
product: Symbolics, LMI, TI, DEC, DG, Gould, Sun, Apollo, Prime,
Tektronix, H-P, Xerox, AT&T, Pyramid, Lucid, Intermetrics, Gold
Hill, and Franz Inc. There is also a strong interest in Japan.
European efforts at defining EuLISP are building on the Common
Lisp experience.
The Common Lisp Community is an informal collection of people
from industry, academia, and government who have particpated in
the initial design and implementation of Common Lisp. This group
has been in existence for five years, communicating primarily by
ARPAnet. Occasionally the community meets, as they did in
Boston, December 9-11, 1985. At that meeting they decided that a
national and international standards effort for Common Lisp was
appropriate and decided to move ahead.
--------------------
Received: FROM SEISMO.CSS.GOV BY USC-ISIF.ARPA WITH TCP ; 15 May 86 19:09:55 PDT
from mcvax.UUCP by seismo.CSS.GOV with UUCP; Thu, 15 May 86 20:34:06 EDT
by mcvax.uucp; Thu, 15 May 86 22:08:33 +0200 (MET)
by inria.UUCP; Thu, 15 May 86 20:50:57 -0100 (MET)
Date: Thu, 15 May 86 20:50:57 -0100
From: mcvax!inria!queinnec@seismo.CSS.GOV (Christian Queinnec)
To: Mathis@USC-ISIF.ARPA
Return-Path: <mcvax!inria!queinnec@seismo.CSS.GOV>
<mcvax!inria!queinnec>
Message-ID: <8605151950.AA07594@inria.UUCP>
Here is the proposal of the Lisp experts group from AFNOR for a New
Work Item. This proposal will be submitted to Mr Mathis for opening
discussion. This is quite short because i only have to fill a form
with little space devoted to text, but the items listed cover the
main issues we expect of this standard.
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
Draft Proposal for a New Work Item
15/May/1986 ISO/TC97/SC22
Title : Specifications for computer programming Language LISP
Purpose : the standard will specify 1) the syntax and semantics of the language
2) the conformity requirements 3) the host operating system requirements
3) the run-time libraries definitions 4) the mechanisms to build
developpment environnement libraries.
The standard will provide 1) equal semantics between interpreted and
compiled execution 2) efficient implementations on general purpose
computers 3) true portable applications (including graphics, mouse device,
windowing systems, objects, error handling ...).
Existing Documents :
"Common-Lisp : The language", Digital Press
"Eu←Lisp Proposals for an International Standard", (available from AFNOR)
Other comments : If approved by TC97 and if NWI is assigned to SC22, SC22
will establish a new Working Group.
←←←←←←←←←←←←←←←←←←
Christian Queinnec
--------------------
End forwarded messages
∂15-May-86 2000 RPG
∂15-May-86 1925 mcvax!inria!queinnec@seismo.CSS.GOV
Received: from SEISMO.CSS.GOV by SU-AI.ARPA with TCP; 15 May 86 19:25:37 PDT
Return-Path: <mcvax!inria!queinnec>
Received: from mcvax.UUCP by seismo.CSS.GOV with UUCP; Thu, 15 May 86 20:36:42 EDT
Received: by mcvax.uucp; Thu, 15 May 86 22:10:10 +0200 (MET)
Received: by inria.UUCP; Thu, 15 May 86 20:51:57 -0100 (MET)
Received: by inria.UUCP; Thu, 15 May 86 20:50:43 -0100 (MET)
Date: Thu, 15 May 86 20:50:43 -0100
From: mcvax!inria!queinnec@seismo.CSS.GOV (Christian Queinnec)
Message-Id: <8605151950.AA07592@inria.UUCP>
To: mcvax!eulisp@seismo.CSS.GOV
Here is the proposal of the Lisp experts group from AFNOR for a New
Work Item. This proposal will be submitted to Mr Mathis for opening
discussion. This is quite short because i only have to fill a form
with little space devoted to text, but the items listed cover the
main issues we expect of this standard.
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
Draft Proposal for a New Work Item
15/May/1986 ISO/TC97/SC22
Title : Specifications for computer programming Language LISP
Purpose : the standard will specify 1) the syntax and semantics of the language
2) the conformity requirements 3) the host operating system requirements
3) the run-time libraries definitions 4) the mechanisms to build
developpment environnement libraries.
The standard will provide 1) equal semantics between interpreted and
compiled execution 2) efficient implementations on general purpose
computers 3) true portable applications (including graphics, mouse device,
windowing systems, objects, error handling ...).
Existing Documents :
"Common-Lisp : The language", Digital Press
"Eu←Lisp Proposals for an International Standard", (available from AFNOR)
Other comments : If approved by TC97 and if NWI is assigned to SC22, SC22
will establish a new Working Group.
←←←←←←←←←←←←←←←←←←
Christian Queinnec
∂15-May-86 2057 FAHLMAN@C.CS.CMU.EDU iso work on Lisp
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 15 May 86 20:57:42 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 15 May 86 23:58:44-EDT
Date: Thu, 15 May 1986 23:58 EDT
Message-ID: <FAHLMAN.12207040954.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: MATHIS@USC-ISIF.ARPA
Cc: cl-steering@SU-AI.ARPA
Subject: iso work on Lisp
In-reply-to: Msg of 15 May 1986 22:32-EDT from MATHIS at USC-ISIF.ARPA
I'm not sure how it is supposed to work in ISO when two groups want to
standardize the same thing in two incompatible ways. Do we both develop
proposals and then fight it out, or are we supposed to fight it out now?
Or is the convenor supposed to try to reconcile the two groups? What
exactly does a New Work Item mean?
Our position, I think, is that Common Lisp as described in ClTL is
already a de facto standard, and we intend to propose an official
standard that reflects this. Any changes will be considered in the
light of their effect on existing user code and implemenations;
incompatible changes will only be adopted if the benefits clearly
outweigh the costs. From what they have said in the past, the Europeans
intend to propose lots of gratuitous incompatibilities -- they didn't
get to play as Common Lisp was being designed, so now they feel free to
change everything they don't like, such as the type of NIL.
I think that these are fundamentally incompatible goals. A compromise
that would let them make just a few incompatible changes is as bad as
letting them redesign the whole language; the existing Common Lisp
community wouldn't buy gratuitous changes at this point just to make the
language more elegant in some eyes. The only other kind of compromise
that I can see is to let us do "ISO Common Lisp" while they try to
develop an "ISO EuLisp", but they seem to reject this since they want to
do "ISO LISP" and they have stated that the current Common Lisp should
not be standardized since it offends their sense of elegance. So unless
the Europeans relent, I think we have to go through whatever process is
invoked when irreconcilable differences arise in the standards process.
If we lose, we've still got ANSI, I guess.
If it comes to a shootout, they've got a few experts, but we've got
heavier ones. I'm not sure how we'd stack up in terms of publication
count, but we certainly have more practical experience by any
conceivable measure. We've also got a large and growing user community
and all of the major U.S. companies, which ought to count for
something. The Europeans are still trying to decide how to define what
a "Lisp" is, and they have nothing remotely resembling a complete
design, let alone implementations. So far, they've postponed all of the
kinds of decisions that lead to real disagreements. On the other hand,
the Europeans probably have the votes of more countries than do right
now, though I suppose we could start recruiting in the third world.
-- Scott
∂16-May-86 1507 MATHIS@USC-ISIF.ARPA Re: iso work on Lisp
Received: from USC-ISIF.ARPA by SU-AI.ARPA with TCP; 16 May 86 15:07:49 PDT
Date: 16 May 1986 14:10-PDT
Sender: MATHIS@USC-ISIF.ARPA
Subject: Re: iso work on Lisp
From: MATHIS@USC-ISIF.ARPA
To: Fahlman@C.CS.CMU.EDU
Cc: cl-steering@SU-AI.ARPA
Message-ID: <[USC-ISIF.ARPA]16-May-86 14:10:01.MATHIS>
In-Reply-To: <FAHLMAN.12207040954.BABYL@C.CS.CMU.EDU>
Scott, Thanks for those comments. I am planning to go to the
next EuLisp meeting in Bath, England on June 2. My purpose is to
try to achieve some compromise that allows work to go forward on
what we think of as Common Lisp. Your point is well taken ( and
I depend on you and others from the technical and steering
committees to continue to remind me) that sometimes a compromise
is really just giving up. If Mary wants the whole piece and John
says let's each take half, it is not a compromise to give
three-fourths to Mary. I'm sorry, it may be a compromise, but it
is not fair or reasonable.
I'll have more on this to say later. I also want to hear from
other people. -- Bob
∂16-May-86 1810 Bobrow.pa@Xerox.COM Re: iso work on Lisp
Received: from XEROX.COM by SU-AI.ARPA with TCP; 16 May 86 18:10:10 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 16 MAY 86 17:46:19 PDT
Date: 16 May 86 17:46 PDT
From: Bobrow.pa@Xerox.COM
Subject: Re: iso work on Lisp
In-reply-to: MATHIS@USC-ISIF.ARPA's message of 16 May 86 14:10 PDT
To: MATHIS@USC-ISIF.ARPA
cc: Fahlman@C.CS.CMU.EDU, cl-steering@SU-AI.ARPA
Message-ID: <860516-174619-1022@Xerox>
To what extent can we consider the following to make EU happy?
a) subsets of CommonLisp
b) alternatives that are additive
c) alternatives that can be made additive
by loading a support file.
The latter two keeps backwards compatability at th cost of agreeing on a
union that is acceptable, and the first allows smaller upwards growing
parts.
I agree that changes that harm current users must be very important to
be accepted.
∂16-May-86 1916 FAHLMAN@C.CS.CMU.EDU iso work on Lisp
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 16 May 86 19:16:48 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 16 May 86 22:17:55-EDT
Date: Fri, 16 May 1986 22:17 EDT
Message-ID: <FAHLMAN.12207284746.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Bobrow.pa@XEROX.COM
Cc: cl-steering@SU-AI.ARPA
Subject: iso work on Lisp
In-reply-to: Msg of 16 May 1986 20:46-EDT from Bobrow.pa at Xerox.COM
To what extent can we consider the following to make EU happy?
a) subsets of CommonLisp
b) alternatives that are additive
c) alternatives that can be made additive
by loading a support file.
My own opinion, which I have expressed to Chailloux on several
occasions:
I've never had any problem with some group going off and defining a
subset, or more than one, as long as they don't create too much
confusion about what the "real" Common Lisp is. That means that if it
claims to be a subset, it must really be a subset and not some
incompatible simplification. And that if a multiple-level standard is
created, the name "Common Lisp" is reserved for the language we
currently have; the others are Common Lisp "subsets" or "kernels" or
something like that, and not "Common Lisp, Level 1". And even the
naming issue might be negotiable.
I personally think that making an official subset is a waste of time.
Any machine with virtual memory can easily support the full language,
and for delivery of critical applications on small machines, the subset
you want is whatever subset you happen to have used. There are simple
GC techniques that flush most of the unused stuff once you're done with
development. I think that if you do want a subset, you want a different
subset for each application: education, CAD, symbol-crunching, writing
editors, and so on. But while I personally have no interest in subsets,
it does no harm if someone goes off and defines one, even if they
make it official. So if that's all it would take to make them happy, I
have no objection.
Chailloux, in private discussions, has said he wants a compatible Common
Lisp subset, but Fitch, Padget, and Stoyan want to clean everything up.
They have stated at various times that Common Lisp should not be
standardized in its current state -- they use the word "standard" to
mean some Platonic ideal of the perfect Lisp. So maybe we could entice
the INRIA people with this offer, but not the others. Even if they
agreed that we get to do Common Lisp while they do subsets, there might
be problems with other groups interested in subsets, including Ida in
Japan, Gold Hill, and Kessler at Utah. All have different ideas.
I have also said to Chailloux that if they have specific ideas for
changes, we would be happy to consider them, especially if they take the
form of compatible extensions. That is not to say that we would accept
whatever changes that they propose -- no blank checks in this business.
But I don't think they're into extensions, from the technical material
I've seen so far. They want to clean things up in fundamental ways and
make the whole language more Scheme-like, on the one hand, and to
preserve their existing investment in the code for LeLisp and Cambridge
Lisp on the other hand. And they have this weird concern for what kind
of minimal Lisp can be done on a Z-80. Why they didn't pick a PDP-8, I
don't know!
I don't want to fight with these people. The split is partly our fault
for not having found some way of including them in the original design
discussions. We should be as accommodating as possible, on all
dimensions, without taking the fatal step of allowing them to dictate
incompatible changes in the existing Common Lisp. I'd really like to
bring the Eulisp people into the fold, but they're academics, and if
they want to be stubborn they don't have to pay attention to the rest of
the world or to the kinds of concerns that come up when you need to sell
a made-up standard to real companies with real users. If they insist
upon being unreasonable and on trying to keep the current Common Lisp
out of ISO, we'll just have to fight it out. They have about a dozen
people involved in Eulisp, more or less. I'm happy to listen to their
ideas, but in a sane world there's no way they should be able to dictate
terms to 30 or so major companies hundreds of people involved in
implementation efforts, and a Common Lisp user community that already
numbers in the thousands and is growing fast.
-- Scott
∂16-May-86 2139 RPG ISO Lisp
To: cl-steering@SU-AI.ARPA
There are several possible solutions to the EuLisp problem:
1. Convince them that there should be an `ISO Common Lisp,'
an `ISO EuLisp,' and in 10 years, an `ISO Lisp.'
2. Convince them to make EuLisp a Lisp in which Common
Lisp can be easily and efficiently implemented. I suppose
this could be considered a subset of Common Lisp, but
more likely it is a Lisp implementation language.
3. Work with the European manufacturers to:
a. get more European votes, if possible
b. get them to see that their academic interests
are not totally applicable, even in Europe.
I presume that ISO voting in Europe cannot be by a self-appointed,
small number of people.
4. Start investigating ways to sidestep the `if there is an ISO
standard, the US military (?) must use it' problem. In this
case, the US and our Common Lisp friends can vote against
EuLisp, and we can go our separate ways.
I would guess that the only real problem is if ISO adopts EuLisp and
not Common Lisp. I suppose there are more ambitious compromises that
involves starting the work on a true platonic Lisp, but I'm not sure
my stamina is up to that.
-rpg-
∂17-May-86 0741 FAHLMAN@C.CS.CMU.EDU ISO Lisp
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 17 May 86 07:41:07 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 17 May 86 10:42:11-EDT
Date: Sat, 17 May 1986 10:42 EDT
Message-ID: <FAHLMAN.12207420239.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Dick Gabriel <RPG@SU-AI.ARPA>
Cc: cl-steering@SU-AI.ARPA
Subject: ISO Lisp
In-reply-to: Msg of 17 May 1986 00:39-EDT from Dick Gabriel <RPG at SU-AI.ARPA>
I agree with RPG's analaysis, and share his lack of enthusiasm for
starting over.
I've been assuming that if we get an ANSI standard for Common Lisp, the
U.S. military and friends will be free to shoose that over an
incompatible ISO standard. Is that right? Presumably some foreign
governments and researchers will not have that freedom; that gives them
some incentive to vote for us rather than EuLisp if it comes down to a
choice at ISO. If the vote doesn't come up for a year or so, the
dominance of Common Lisp will be very clear, since all of the
manufacturers will have their implementations out and in good shape by
then, all of the major expert-system shells will be converted, and the
research community will have made the move. Right now we can see that
the necessary momentum is there, but from the outside it may not be so
clear since lots of things are just in beta-test or unannounced.
-- Scott
∂27-May-86 0605 FAHLMAN@C.CS.CMU.EDU [franz!fimass!jkf: Where we stand ]
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 27 May 86 06:04:52 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 27 May 86 09:03:58-EDT
Date: Tue, 27 May 1986 09:03 EDT
Message-ID: <FAHLMAN.12210023783.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-steering@SU-AI.ARPA
Subject: [franz!fimass!jkf: Where we stand ]
Date: Tuesday, 27 May 1986 02:02-EDT
From: franz!fimass!jkf at kim.Berkeley.EDU (John Foderaro)
To: Scott E. Fahlman <ucbkim!C.CS.CMU.EDU!Fahlman at kim.Berkeley.EDU>
Re: Where we stand
I believe that using the Steele book, or any other document of that
form, would be a mistake for a basis for a standard. The book is
written in good English which has its advantages (being thoroughly
enjoyable and subtly witty) and its disadvantages (being incompletly
specified and at times totally ambiguous). What we need is a
excruciatingly dull document which has the form:
1. definitions of terms
2. functions and special forms, alphabetically.
3. special symbols
Each function is defined using simple English and the terms defined in
the beginning.
Appendicies could be added to flesh out sections of functions (such
as the error system or defstruct), but in all cases the official
definition is in the main part of the manual.
The form of the function descriptions could be in a neutral format
from which one could convert it to any of the popular typesetting
languages using a filter.
For example:
function: cons
arguments: x (any-lisp-object)
y (any-lisp-object)
action: Allocate and return a new object of type cons initiatialing the car
slot to x and the cdr slot to y.
This would help promote an international standard since it will make
the translation to other languages easier. I've met someone who
is translating the Steele book to Japanese and I was suprised at the
number of important concepts he has wrong (and his readers will get
wrong).
john foderaro
franz inc.
∂27-May-86 0620 FAHLMAN@C.CS.CMU.EDU Where we stand
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 27 May 86 06:20:37 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 27 May 86 09:19:47-EDT
Date: Tue, 27 May 1986 09:19 EDT
Message-ID: <FAHLMAN.12210026673.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: franz!fimass!jkf@λkim.Berkeley.EDU (John Foderaro)λ
Cc: cl-steering@SU-AI.ARPA
Subject: Where we stand
In-reply-to: Msg of 27 May 1986 02:02-EDT from franz!fimass!jkf at kim.Berkeley.EDU (John Foderaro)
John,
I understand your concern about the format of the Steele book, and share
it. I think there may be some middle ground between the current book
and "excruciatingly dull" that would allow us to produce a very precise
spec that is also useful as a manual for the working programmer (though
it would certainly not be a good introductory text for the language).
If we can do that, we will prevent the confusion that would arise due to
differences between the official spec and whatever more readable manual
everyone ends up using.
I think that the spec has two kinds of things in it: very precise
descriptions of each of the functions, forms, and built-in variables,
and some conceptual material explaining, for example, how scoping or
packages work in Common Lisp. For the descriptions, the kind of format
you describe (and that we see coming from the Eulisp effort) is indeed
what we want. The Lucid manual is already organized more or less this
way, which is the reason I'd like to get it as a starting point. (We
would have to go over it carefully to get rid of any Lucid-specific
stuff and make sure it really does match Steele.)
For the descriptive material, the Steele book has some useful chunks of
text that I'd like to be able to lift. This text has the advantage that
people have been scrutinizing it for a couple of years, so we know where
most of the ambiguities are. If we write something new, we'll be
discovering new problems for awhile after the user community gets hold
of the new text.
I think that this mixture of formats would be good for online use. One
could create a cross-index of function-description frames, and pointers
to the appropriate chunk of explanatory text where needed.
My inclination is to go with Tex for the new document, as this seems to
be the most widespread text-formatter around. (I won't use any of those
evil hacks with "roff" in the name, and Scribe (TM) is too expensive for
some groups.) If we use Tex macros in a consistent way, automated
conversion to other formatters would be just as easy as if we used raw
text in a rigid format, but the advantage is that we can quickly run off
decent-looking working documents as we go.
Anyway, that's my current thinking on the matter. I'm still pretty
flexible on this. Once we have access to the various sources and can
start putting this together, we can see how various organizations work
out in practice.
-- Scott
∂27-May-86 1154 RPG Mark Your Calendars
To: cl-steering@SU-AI.ARPA
CC: rhh@MC.LCS.MIT.EDU
There will be a meeting of the object-oriented programming group after the
Lisp conference. I will ask Bert Halstead to find a room at MIT or
Symbolics that will hold around 50 - 100 people. I propose that it be
held starting around 2pm on the last day of the Lisp conference, 2pm being
after the conference is over. Shall I send this out over the main mailing
list?
On another note, let me bring you up to date on the Lucid manual
situation. There is a major, unexpected complication in the use of the
manual. The best situation for us (this committee) is that Lucid allows a
derived work with little or no constraint. However, suppose Lucid simply
agrees to that, and the derived work is not sufficiently different from
the original that the usual copyright tests would fail; that is, that the
derived work would have been judged a copyright enfringement of the
original. The fact that Lucid released the derived work implies a release
of the original. The lawyers can solve this, but none of us would want to
sign that document.
Bob Mathis and Lucid's lawyers are proceeding on this front, though
slowly.
-rpg-
∂27-May-86 1234 Moon@SAPSUCKER.SCRC.Symbolics.COM Where we stand
Received: from [192.10.41.223] by SU-AI.ARPA with TCP; 27 May 86 12:33:04 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 23653; Tue 27-May-86 15:28:35 EDT
Date: Tue, 27 May 86 15:22 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Where we stand
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>
cc: cl-steering@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12210026673.BABYL@C.CS.CMU.EDU>
Message-ID: <860527152215.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 27 May 1986 09:19 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
[Recipient removed: John Foderaro]
....
My inclination is to go with Tex for the new document, as this seems to
be the most widespread text-formatter around. (I won't use any of those
evil hacks with "roff" in the name, and Scribe (TM) is too expensive for
some groups.) If we use Tex macros in a consistent way, automated
conversion to other formatters would be just as easy as if we used raw
text in a rigid format, but the advantage is that we can quickly run off
decent-looking working documents as we go.
I take it you decided to ignore my contention that the only viable format
for working documents is straight text with no formatting commands obscuring it?
∂27-May-86 1247 FAHLMAN@C.CS.CMU.EDU Where we stand
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 27 May 86 12:46:49 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 27 May 86 15:45:05-EDT
Date: Tue, 27 May 1986 15:44 EDT
Message-ID: <FAHLMAN.12210096801.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: cl-steering@SU-AI.ARPA
Subject: Where we stand
In-reply-to: Msg of 27 May 1986 15:22-EDT from David A. Moon <Moon at SCRC-STONY-BROOK.ARPA>
I take it you decided to ignore my contention that the only viable format
for working documents is straight text with no formatting commands obscuring it?
No, but I decided to disagree with it. As I said at the time in mail I
hope you got, I think that having a way of quickly whipping up a
decent-looking document with an index, visible section headings, and
some way of getting at distinctive fonts for emphasis and for code
examples will be valuable during the development process. I don't think
that a lot of effort should go into making the document beautiful at
this point, but I want it to be reasonably functional and not just
80-column uglitext for reading on terminals.
If the others feel as you do, I'd be willing to discuss this, but I got
the impression that you were the only one who held this view. The one
who does the work of assembling the new document gets a slightly bigger
vote, I think.
-- Scott
∂27-May-86 1352 ALAN@AI.AI.MIT.EDU Where we stand
Received: from AI.AI.MIT.EDU by SU-AI.ARPA with TCP; 27 May 86 13:52:03 PDT
Date: Tue, 27 May 86 16:52:10 EDT
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject: Where we stand
To: Fahlman@C.CS.CMU.EDU
cc: cl-steering@SU-AI.ARPA, Moon@SCRC-STONY-BROOK.ARPA
In-reply-to: Msg of Tue 27 May 1986 15:44 EDT from Scott E. Fahlman <Fahlman at C.CS.CMU.EDU>
Message-ID: <[AI.AI.MIT.EDU].46661.860527.ALAN>
Date: Tue, 27 May 1986 15:44 EDT
From: Scott E. Fahlman <Fahlman at C.CS.CMU.EDU>
No, but I decided to disagree with it. As I said at the time in mail I
hope you got, I think that having a way of quickly whipping up a
decent-looking document with an index, visible section headings, and
some way of getting at distinctive fonts for emphasis and for code
examples will be valuable during the development process. I don't think
that a lot of effort should go into making the document beautiful at
this point, but I want it to be reasonably functional and not just
80-column uglitext for reading on terminals.
While there is something to be said for the ability to generate passable
hardcopy, I have yet to see a text-justifier that has a notation for font
shifts that doesn't render the input text unreadable. TeX's notation is
perhaps the worst of the bunch.
When generating documentation myself, I generally stick to a few simple,
readable conventions to indicate -emphasis-, CODE, <meta-variables>,
.section names, etc. Then a couple of TECO macros generally suffice to
convert the result to TeX input or whatever, when the time comes for fancy
output. I don't know if a group can work this way, but it sure would be
nice to be able to work with readable text. I want to be able to get
proposed text in my mailbox, and not have to run it through TeX in order to
read it without donning my kludge-proof goggles.
Look at it this way, this document is for communication among ourselves
almost as much as it is for communication with the rest of the world.
∂27-May-86 1454 DLW@SCRC-QUABBIN.ARPA Format of manual
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 27 May 86 14:54:03 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 2491; Tue 27-May-86 17:52:50 EDT
Date: Tue, 27 May 86 17:55 EDT
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN>
Subject: Format of manual
To: cl-steering@sail
Message-ID: <860527175521.2.DLW@CHICOPEE.SCRC.Symbolics.COM>
I agree with Scott's message. I've spent many hours working on Lisp
documentation (the Lisp Machine Manual), and there's one point I'd like
to respond to: descriptions of individual functions are the easiest
thing to write. While the existing CLtL isn't sufficiently specific in
its descriptions of some functions, this is not its primary problem.
The real hard part in writing such documentation is explaining the
concepts. This is particularly hard when you're writing a standards
document, that needs to be very precise. While I agree that the
stylized form of function documentation that JKF suggested, and that the
Lucid documentation uses, is a good thing, it should not be viewed as
the most important change towards producing a clear and specific manual.
In my experience, there is an important tradeoff between writing a
manual useful for a reader who's learning what the manual says, and
writing a manual that's very clear and specific. It's hardly impossible
to do some of each, but it's very hard, because often one goal gets in
the way of the other.
I'd recommend that the guideline for the new CL spec is that it should
attempt to present the material in a logical, ordered fashion that
builds from the bottom to the top, and it should attempt to assume that
the reader is not yet familiar with concepts not yet presented, but it
should above all be strict and precise, even if this conflicts with the
other goals.
The balance is subtle and hard to measure precisely. I agree with Scott
that we'll have to experiment some to find the right tradeoff. I also
agree that starting with the existing material, and modifying it to be
closer to what we want, is more likely to succeed than an attempt to
start from scratch.
∂27-May-86 1518 FAHLMAN@C.CS.CMU.EDU Where we stand
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 27 May 86 15:18:14 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 27 May 86 18:16:35-EDT
Date: Tue, 27 May 1986 18:16 EDT
Message-ID: <FAHLMAN.12210124396.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Cc: cl-steering@SU-AI.ARPA, Moon@SCRC-STONY-BROOK.ARPA
Subject: Where we stand
In-reply-to: Msg of 27 May 1986 16:52-EDT from Alan Bawden <ALAN at AI.AI.MIT.EDU>
When generating documentation myself, I generally stick to a few simple,
readable conventions to indicate -emphasis-, CODE, <meta-variables>,
.section names, etc. Then a couple of TECO macros generally suffice to
convert the result to TeX input or whatever, when the time comes for fancy
output. I don't know if a group can work this way, but it sure would be
nice to be able to work with readable text. I want to be able to get
proposed text in my mailbox, and not have to run it through TeX in order to
read it without donning my kludge-proof goggles.
It seems to me that it would be somewhat easier to create a set of TECO
macros to strip off any TEX formatting stuff you don't want to see. It
takes a serious amount of AI for a teco macro to know whether "I" in
some text is normal English or if it is a variable name that should be
converted to computerfont.
My view is that at least half the time I'm going to be looking at the
paper version of this stuff, and I want that to look halfway decent.
The rest of the time I'll be looking at it on a workstation with a
hi-res screen, and if I don't like the way the TeX input looks there,
it's easy enough to whip up some kludge that display TeX files in some
approximation to how they will look on paper.
-- Scott
∂27-May-86 1545 Moon@SAPSUCKER.SCRC.Symbolics.COM Where we stand
Received: from [192.10.41.223] by SU-AI.ARPA with TCP; 27 May 86 15:45:07 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 23730; Tue 27-May-86 18:40:32 EDT
Date: Tue, 27 May 86 18:41 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Where we stand
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>
cc: cl-steering@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12210124396.BABYL@C.CS.CMU.EDU>
Message-ID: <860527184125.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Character-Type-Mappings: (1 0 (NIL 0) (NIL :ITALIC NIL) "CPTFONTI")
Fonts: CPTFONT, CPTFONTI
Date: Tue, 27 May 1986 18:16 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
My view is that at least half the time I'm going to be looking at the
paper version of this stuff, and I want that to look halfway decent.
The rest of the time I'll be looking at it on a workstation with a
hi-res screen, and if I don't like the way the TeX input looks there,
it's easy enough to whip up some kludge that display TeX files in some
approximation to how they will look on paper.
And how much of the time will you be spending editing it?
I wonder if I could get you to commit to "whipping up some kludge" that
you will run over the text every time you send stuff to me to read so I
can read it, and every time I send edited stuff to you, you will run it
over it again to turn it back into the format that you like. I doubt
that I could. I hope you get my point, which is not at all "Fahlman is
intransigent and uncooperative" (or substitute "Moon" for "Fahlman" if
you like). My point is that we ought to be concentrating on the content
of this stuff, not the appearance. If the appearance won't take care of
itself, it at least does not require the specialized skills of
high-powered language designers.
Two related points: (1) If I have to wade through a sea of backslashes,
curly brackets, atsigns, or any other garbage, I'm a lot less likely to
notice that we forgot to say whether or not FORMAT ~A is affected by the
value of *PRINT-PRETTY*. (2) People like you and I are very easily
distracted into debugging our Tex macros or making the "last" tweak so
something looks pretty on paper, instead of doing what we are supposed
to be doing. Let's leave the book design to the book designers and the
typography to the typographers (and for God's sake let's leave the
litigation to the lawyers) and not erect unnecessary obstacles to getting
the language design accomplished by the language designers. And, oh yes,
I promise to take the ε1character-style shiftsε0 off before I send anything
to you; everybody has their own garbage that somebody else doesn't want
to wade through.
∂27-May-86 1658 JAR@MX.LCS.MIT.EDU text
Received: from [10.1.0.6] by SU-AI.ARPA with TCP; 27 May 86 16:58:01 PDT
Date: Tue, 27 May 86 19:57:22 EDT
From: Jonathan A Rees <JAR@MX.LCS.MIT.EDU>
Subject: text
To: cl-steering@SU-AI.ARPA
In-reply-to: Msg of Tue 27 May 86 16:52:10 EDT from Alan Bawden <ALAN at AI.AI.MIT.EDU>
Message-ID: <[MX.LCS.MIT.EDU].922039.860527.JAR>
I agree with Bawden and Moon. We should try to come up with a notation
that's much simpler and more readable than TeX.
Jonathan
∂27-May-86 2123 FAHLMAN@C.CS.CMU.EDU Where we stand
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 27 May 86 21:22:52 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 28 May 86 00:10:42-EDT
Date: Wed, 28 May 1986 00:10 EDT
Message-ID: <FAHLMAN.12210188849.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: cl-steering@SU-AI.ARPA
Subject: Where we stand
In-reply-to: Msg of 27 May 1986 18:41-EDT from David A. Moon <Moon at SCRC-STONY-BROOK.ARPA>
Well, those are all pretty good arguments, and it looks like you've got
me outnumbered, three votes to one. And my heart is certainly not set
on using TeX -- I've used Scribe for the past eight years, though I've
been meaning to move over to TeX for the last two of those years. It
seems clear to me that the final document is going to be done in TeX,
since it is the least obnoxious formatting system that is available on
just about every machine, but I guess we can hire some semi-technical
coolie to format the document and do an index at the end.
In my view, pretending to pass around chunks of the manual in English,
but carefully adhering to some set of conventions that can be
machine-translated into TeX (or whatever), would be more of a
distraction than writing in a real formatting language in the first
place. If it's going to be English, let's just use any natural language
conventions that we all understand. Bawden can say -potato- and I can
say POTATO, and if both forms find their way into the evolving manual,
the guy who does the final formatting can sort it all out into TeX.
Let me suggest the following: If we start from scratch, we'll write the
manual in something like plain English and add the formatting, whatever
it is, at the end. If we start with either the Steele book or the Lucid
book (both of which are now in TeX, I believe), and if the editing is
mostly done here at CMU, I want to reserve the right to continue in TeX
rather than scraping it all away, making changes, and having to add it
all back in at the end. But if we go that way, we'll run the document
through TeX whenever changes are made and create a plain-English file
from it. We can have our discussions in terms of the English version,
people writing proposed changes can use English, and you'll never have
to know that I'm keeping things in TeX behind your backs.
Since you offer, I would prefer not to see those ↑F's, and I'll try not
to use @i[...] too much. I'm tempted to propose that we also agree
never to go over 80-columns, even when responding to nested mail
messages, because the wraparaound is infinitely more distracting to me
than any possible text-formatting garbage. But if I proposed that you'd
all taunt me for not hacking my mail on a -REAL- machine.
-- Scott
∂30-May-86 0745 FAHLMAN@C.CS.CMU.EDU Foreigners
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 30 May 86 07:45:03 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 30 May 86 10:44:21-EDT
Date: Fri, 30 May 1986 10:44 EDT
Message-ID: <FAHLMAN.12210828480.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-steering@SU-AI.ARPA
Subject: Foreigners
I never received any feedback on my proposal that we go ahead and invite
the JEIDA committeee to nominate someone for the steering and technical
committees. (This will probably be Ida.) Before we start voting on
things, which will start soon, I'd like to make this gesture. It could
make a big difference in the enthusiasm with which the Japanese accept
our work, and they are our best potential ally outside the U.S., not to
mention being a substantial fraction of the potential user community.
Shall we move on this?
I'm not sure whether it is worthwhile asking the Europeans if they are
interested in joining right now. Maybe we should wait till Bob Mathis
returns from the Eulisp meeting, where he can see what the mood is over
there. He could quietly inform Chailloux and any other non-radicals
over there that we would like to have a European or two in the inner
loop if we can find one who subscribes to the goal of standardizing the
current Common Lisp without major changes.
-- Scott
∂30-May-86 1257 MATHIS@USC-ISIF.ARPA Foreigners
Received: from USC-ISIF.ARPA by SU-AI.ARPA with TCP; 30 May 86 12:57:24 PDT
Date: 30 May 1986 12:38-PDT
Sender: MATHIS@USC-ISIF.ARPA
Subject: Foreigners
From: MATHIS@USC-ISIF.ARPA
To: CL-Steering@SU-AI.ARPA
Cc: Mathis@USC-ISIF.ARPA
Message-ID: <[USC-ISIF.ARPA]30-May-86 12:38:19.MATHIS>
I was a little worried when Scott used this subject heading; I
thought he might be taking about other language type people.
I thought we had all converged on Ida. The only question seemed
to be how to bring him in -- direct personal invitation or
slection by the Japanese committee. I'll go with whichever Scott
decides. We might offer him at least a provisional place until
the Japanese selection is done.
I hope something positive comes of my trip next week. I will be
talking primarily about procedural and organizational issues.
The point that I have noticed in the discussions on this subset
or minimal set or core language is approximately --
standards for subset languages motivated by machine capacities
are not very useful (eg, Minimal BASIC and the PL/I subset);
there is a strong desire in the Lisp community for minimal
logical basis for the language (who else uses "pure" as a
descriptor?), but practicality is the strongest motivator in the
standardization effort (people are using Common Lisp and what we
need now is a common, standardized definition of that). Everyone
seems interested in discussing a minimal core basis for Lisp, but
that should not delay the currently needed standard for what is
generally understand as Common Lisp.
-- Bob
∂30-May-86 1318 Moon@SCRC-QUABBIN.ARPA Foreigners
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 30 May 86 13:15:24 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 4327; Fri 30-May-86 16:15:47 EDT
Date: Fri, 30 May 86 16:12 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Foreigners
To: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
cc: cl-steering@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12210828480.BABYL@C.CS.CMU.EDU>
Message-ID: <860530161241.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Fri, 30 May 1986 10:44 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
I never received any feedback on my proposal that we go ahead and invite
the JEIDA committeee to nominate someone for the steering and technical
committees. (This will probably be Ida.) Before we start voting on
things, which will start soon, I'd like to make this gesture.
As far as I'm concerned, go ahead. (I'm not on the steering committee.)
Dan Weinreb will not be reading his mail until the week after next, but
I would be surprised if he disagreed with my opinion on this particular issue.
∂31-May-86 1927 FAHLMAN@C.CS.CMU.EDU Proposed message
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 31 May 86 18:55:24 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 31 May 86 21:55:11-EDT
Date: Sat, 31 May 1986 21:55 EDT
Message-ID: <FAHLMAN.12211212771.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-steering@SU-AI.ARPA
Subject: Proposed message
Just to make it all specific, here is the message that I propose sending
to Professor Ida sometime soon. Let me know if you disagree with this
action, or if you have any amendments. After a few days, I will take
silence as agreement.
I'm not sure who the message should be signed by. I'm happy enough to
do this as "Scott Fahlman, on behalf of the Common Lisp Steering and
Technical Committess", but it's more of a steering-type function.
-- Scott
---------------------------------------------------------------------------
Dear Professor Ida:
Now that we have reliable network communications with Japan, the Common
Lisp group in the U.S. would very much like to encourage Japanese
participation in our efforts to clarify and standardize the Common Lisp
specification. The members of the Technical and Steering committess
have been discussing for some time how we might include our Japanese
counterparts in the decision-making process. After discussing the
matter with several Japanese researchers, we believe that the following
model may be the best one to follow:
1. The language design discussions will take place on the public Common
Lisp mailing list. We invite any individual in Japan who is interested
in these issues to follow the discussion on this list and to contribute
to it. We believe that the technical barriers to such participation
have now been eliminated, at least for people with access to Junet or
CSNet. Our discussions are in English, so unless some sort of
translation can be arranged, only English-speaking researchers will be
able to participate directly.
2. It appears that your JEIDA committee on Common Lisp is coordinating
much of the Common Lisp activity in Japan. This should continue to be
the focus for the Japanese Common Lisp community. We will try to
maintain close communications with your committee in the future,
probably via netmail to you and other members.
3. For the purpose of formal liaison between our group and yours, we
would like to invite the JEIDA committee to select one person who will
be a member of our Steering Committee and one person who will be a
member of our Technical Committee. (One person can fill both posts, if
you like.) These members will be invited to any face-to-face committee
meetings we might have, but we expect these to be rare events. We
believe that the Japanese members would be able to participate in
almost all committee decisions, even if he is unable to attend some
meetings in the U.S.
Does this seem like a reasonable plan to you? Are there important
segments of the Japanese Common Lisp community who would not be
represented under this plan? Do you have any other suggestions on how
we might handle this?
If you agree with this plan, we will announce it on the Common-Lisp
mailing list, which many Japanese researchers will see.
Best regards,
Scott Fahlman
(on behalf of the Common Lisp Technical and Steering Committees)
∂01-Jun-86 1507 Bobrow.pa@Xerox.COM Re: Proposed message
Received: from XEROX.COM by SU-AI.ARPA with TCP; 1 Jun 86 15:07:04 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 01 JUN 86 15:07:01 PDT
Date: 1 Jun 86 15:06 PDT
Sender: Bobrow.pa@Xerox.COM
Subject: Re: Proposed message
In-reply-to: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>'s message of Sat,
31 May 86 21:55 EDT
To: Fahlman@C.CS.CMU.EDU
cc: cl-steering@SU-AI.ARPA
From: Bobrow.pa@Xerox.COM (Danny Bobrow)
Message-ID: <860601-150701-1707@Xerox>
Scott,
I like the message. Should we include a description of the difference
between the steering and technical committees (what the former does, for
example)?
----- dgb:
∂01-Jun-86 1522 FAHLMAN@C.CS.CMU.EDU Proposed message
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 1 Jun 86 15:22:11 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 1 Jun 86 18:19:01-EDT
Date: Sun, 1 Jun 1986 18:18 EDT
Message-ID: <FAHLMAN.12211435558.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Bobrow.pa@λXerox.COM (Danny Bobrow)λ
Cc: cl-steering@SU-AI.ARPA
Subject: Proposed message
In-reply-to: Msg of 1 Jun 1986 18:06-EDT from Bobrow.pa at Xerox.COM (Danny Bobrow)
Good idea. The steering and technical committees have been described
earlier on the mailing list, but some of the Japanese have not been
reading this for very long. The following sentence should do it:
"The Steering Committee is concerned with the administrative issues in
developing a proposed standard and submitting it to ANSI and ISO for
formal approval; the Technical Committee is concerned with the technical
content of the proposal."
-- Scott
∂02-Jun-86 1240 OHLANDER@USC-ISIB.ARPA Re: Proposed message
Received: from USC-ISIB.ARPA by SU-AI.ARPA with TCP; 2 Jun 86 12:39:56 PDT
Date: 2 Jun 1986 12:38-PDT
Sender: OHLANDER@USC-ISIB.ARPA
Subject: Re: Proposed message
From: OHLANDER@USC-ISIB.ARPA
To: Fahlman@C.CS.CMU.EDU
Cc: cl-steering@SU-AI.ARPA
Message-ID: <[USC-ISIB.ARPA] 2-Jun-86 12:38:53.OHLANDER>
In-Reply-To: <FAHLMAN.12211212771.BABYL@C.CS.CMU.EDU>
Scott,
I endorse your message and suggest that you should send
it on behalf of the Common Lisp Technical and Steering Committees.
Ron
∂03-Jun-86 1151 RPG Japan
To: cl-steering@SU-AI.ARPA
Stop the presses! I just talked to a group of Japanese visitors,
and they thought that Ida was too young, and that JEIDA was the
wrong way to go to get the Japanese to go along with the standard.
I'll have more details later tonight - I'm on my way to the airport.
-rpg-
∂03-Jun-86 1341 FAHLMAN@C.CS.CMU.EDU Japan
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 3 Jun 86 13:41:29 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 3 Jun 86 16:40:55-EDT
Date: Tue, 3 Jun 1986 16:40 EDT
Message-ID: <FAHLMAN.12211941979.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Dick Gabriel <RPG@SU-AI.ARPA>
Cc: cl-steering@SU-AI.ARPA
Subject: Japan
In-reply-to: Msg of 3 Jun 1986 14:51-EDT from Dick Gabriel <RPG at SU-AI.ARPA>
OK, nothing has happened in public yet and I've sent nothing to Ida, so
we'll wait for the rest of Dick's input.
-- Scott
∂04-Jun-86 1224 RPG Japan
To: cl-steering@SU-AI.ARPA
Yesterday a Japanese tour group came through Lucid, and the
discussion turned towards standardization. I mentioned that
we were thinking of asking JEIDA to appoint a member. One of the
people there was Prof. Haruki Ueno from Tokyo Denki University,
and he said he was Ida's professor. He strongly stated that
although Ida is a good guy, he is too young to command the respect
of the Japanese computing community. Ueno and others pointed out that
unless we worked through the Japanese Information Processing Society,
the process would not be taken seriously. I don't know anything
about this society, but I became a little alarmed by what I heard.
Any thoughts?
-rpg-
∂04-Jun-86 1502 FAHLMAN@C.CS.CMU.EDU Japan
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 4 Jun 86 15:02:44 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 4 Jun 86 18:02:33-EDT
Date: Wed, 4 Jun 1986 18:02 EDT
Message-ID: <FAHLMAN.12212218988.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Dick Gabriel <RPG@SU-AI.ARPA>
Cc: cl-steering@SU-AI.ARPA
Subject: Japan
In-reply-to: Msg of 4 Jun 1986 15:24-EDT from Dick Gabriel <RPG at SU-AI.ARPA>
This is the sort of thing I was afraid of. It may be that there's a
university/industry split in Japan, with Ida and the JEIDA people on one
side and JIPS on the other. Or it may be more complex than that. My
fear is that there may be nobody who is both senior enough to command
the proper respect and also interested in Common Lisp and willing to
devote soem effort to it. I'm not sure what we do then. Maybe ask JIPS
to appoint someone, even if he's only a figurehead, and proceed that
way.
We really do need to get some more data points from senior people over
there, I guess.
-- Scott
∂05-Jun-86 1522 RPG Japanese
To: cl-steering@SU-AI.ARPA
I got this response to a note to Hiroshi Okuno, the lead guy on
the TAO machine project at NTT, who was recommended to me
by Ueno as a contact person for Japanese standardization.
Dick,
I think that Prof. Eichi Wada, Univ. of Tokyo, is the right person
to organize the Lisp Standarization committee in Japan. I sent
several messages to persuade him to organize such a committee and
information on ANSI and ISO standarization of Lisp, but I haven't
received any reply from him. He is the chairman of the programming
language committee of IFIP in Japan (sorry, I don't know the precise
name of the committee, maybe SC22). All Japanese committees of IFIP
belong to IPSJ (Information Processing Society of Japanese, Japanese
equivalent to ACM.) He is also the chairman of WGSYM of IPSJ and
Prof. Ida is one of the co-chairmen. (I was the former co-chairman.)
JEIDA is a private organization concering Lisp Standarization. As you
know, Prof. Ida is the chairman of JEIDA Lisp Subset Committee.
Prof. Wada attended the First Lisp Conference and discussed with Guy.
I don't know whether gls remembered him.
The network address of Prof. Wada is
wada%utokyo-relay.csnet@relay.cs.net
His postal address is
Department of Mathematical Engineering
Faculty of Engineering
University of Tokyo
Hongo, Bunkyo-ku
Tokyo 113, Japan
The postal address of IPSJ is
Information Processing Society of Japan
3-5-8 Shiba-Park, Minato-ku
Tokyo 105, Japan
I'd advise you to send a letter both to Prof. Wada and to IPSJ.
By the way, where did you met with Prof. Ueno? He is one of my best
advisers and friends.
∂10-Jun-86 0656 FAHLMAN@C.CS.CMU.EDU Plans for Lisp Conference
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 10 Jun 86 06:56:35 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 10 Jun 86 09:56:35-EDT
Date: Tue, 10 Jun 1986 09:56 EDT
Message-ID: <FAHLMAN.12213703387.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-steering@SU-AI.ARPA
Subject: Plans for Lisp Conference
We'd better make some firm plans for meetings in and around the Lisp
conference, if we intend to have any. RPG has tentatively scheduled a
meeting on Object-Oriented stuff on the afternoon of Aug 6, after the
conference ends. What else do we need? A meeting among ourselves (as
many as are presnt in Boston)? Some sort of formal session having to do
with X3J13? An open Q&A session for interested members of the public?
Any sort of session during the conference itself? (Probably too late to
schedule that now.) The only big free slot seems to be Tuesday night,
and if we don't move soon, people will have firm travel plans that will
preclude anything before or after.
-- Scott
∂10-Jun-86 0656 MATHIS@USC-ISIF.ARPA EuLisp meeting in Bath -- Private Message
Received: from USC-ISIF.ARPA by SU-AI.ARPA with TCP; 10 Jun 86 06:56:47 PDT
Date: 10 Jun 1986 06:56-PDT
Sender: MATHIS@USC-ISIF.ARPA
Subject: EuLisp meeting in Bath -- Private Message
From: MATHIS@USC-ISIF.ARPA
To: cl-steering@SU-AI.ARPA
Message-ID: <[USC-ISIF.ARPA]10-Jun-86 06:56:06.MATHIS>
PRIVATE MESSAGE
I have just returned from the EuLisp meeting in Bath, England, on
June 2, 1986. I have three reports which I will send to you from
that meeting. One is a two page summary, another is a preprint of
their paper for the August Lisp Conference, and the third is a
draft of their proposal. These are hard copy documents so I need
regular mailing addresses. I have good addresses for Fahlman,
Gabriel, Moon, Ohlander, Squires, and Weinreb (in the mail this
afternoon). Anybody else who wants copies should give me a good
mailing address.
The first two discuss their subsetting idea as mostly a
definitional approach to defining their level-2 language, which
should be very much like Common Lisp. There was very little talk
of implementing their level-0 (sort of like Scheme), but there
did seem to be some concern about implementations and useability
of their level-1. The meeting brought out some disagreement
between the members of the group about doing things the Common
Lisp way or doing things the "right" way. When an ISO group is
formed, some Common Lisp decisions will have to be revisited in
forming a consensus, but don't be surprised if a lot of the
Europeans back the existing Common Lisp approach (and of course
others oppose it). The ones who wanted to change a lot of things
did not seem to have very strong support within the group (but
remember they were on their good behavior for a foreign visitor).
The third report is the beginning draft of their proposal. This
is a very private document of theirs which they must have assumed
I would circulate, but I wouldn't want to make a big deal about
it. It was mainly drafted by Herbert Stoyan of Erlangen, Germany.
Some parts of it have evidently been lost in electronic
transmission and editing. They hope to have it finished by their
next meeting (early July) and have it available at the August
Lisp meeting in Boston. There is some real anti-Common Lisp
phrasing in it, to which a number of the people at the meeting
objected.
Attendance: Jeff Dalton (AI Appls Inst, Edinburgh); John Fitch
(Univ of Bath); Timm Krumnack (Krupp-Atlas Elecktronik, Germany);
Eugen Neidl (Lab de Marcoussis, France, they are building a Lisp
machine); Andy Norman (Hewlett-Packard Labs, Bristol, England);
Julian Padget (Univ Bath); Pete Richards (Systems Designers,
Surrey, England, really representing the Symbolics Users Group);
Herbert Stoyan (Univ of Erlangen, Germany); John Sturdy (Univ
Bath, grad student); Quyen Tran (AFNOR, France); Sam Valentine
(Systems Designers, Surrey, England, representing POPLOG); John
Williams (Univ of Sussex, doing Lisp for POPLOG); and Robert
Mathis.
Chailloux was not able to be there. Fitch and Stoyan seemed to be
the leaders of the revisionist group. Padget seemed more neutral.
Dalton seemed more of the Common Lisp defender. The industry
people were mostly listeners. There was very little technical
discussion (but the agenda had been set up that way). I was
there more to listen, but it was clear to me that some of their
arguments were weak (and conversely some were not). The sooner
we can start meeting together, the sooner all of you can begin to
work on them (and vice versa).
I still have to work out the ISO convenorship thing with
Chailloux and France. I have talked with him on the phone since
the meeting. There seems to be a real feeling of exclusion of
Europeans from the Common Lisp decision making. We will need to
expand our committees and we need to think of other ways to
include them.
-- Bob Mathis
∂10-Jun-86 0742 @GUIDO.THINK.COM:gls@AQUINAS.THINK.COM Mailing address
Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 10 Jun 86 07:42:27 PDT
Received: from GUIDO.THINK.COM by Godot.Think.COM; Tue, 10 Jun 86 10:42:03 edt
Date: Tue, 10 Jun 86 10:42 EDT
From: Guy Steele <gls@Think.COM>
Subject: Mailing address
To: MATHIS@USC-ISIF.ARPA, cl-steering@SU-AI.ARPA
Cc: gls@AQUINAS
In-Reply-To: <[USC-ISIF.ARPA]10-Jun-86 06:56:06.MATHIS>
Message-Id: <860610104253.5.GLS@GUIDO.THINK.COM>
Guy L. Steele Jr.
Thinking Machines Corporation
245 First Street
Cambridge, Massachusetts 02142
(617)876-1111
∂10-Jun-86 0943 Bobrow.pa@Xerox.COM Re: Plans for Lisp Conference
Received: from XEROX.COM by SU-AI.ARPA with TCP; 10 Jun 86 09:43:22 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 10 JUN 86 09:33:10 PDT
Date: 10 Jun 86 09:33 PDT
Sender: Bobrow.pa@Xerox.COM
Subject: Re: Plans for Lisp Conference
In-reply-to: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>'s message of Tue,
10 Jun 86 09:56 EDT
To: Fahlman@C.CS.CMU.EDU
cc: cl-steering@SU-AI.ARPA
From: Bobrow.pa@Xerox.COM (Danny Bobrow)
Message-ID: <860610-093310-1800@Xerox>
I can be around on Thursday, if necessary after the Lisp conference.
-- danny
∂10-Jun-86 0943 Bobrow.pa@Xerox.COM Re: EuLisp meeting in Bath -- Private Message
Received: from XEROX.COM by SU-AI.ARPA with TCP; 10 Jun 86 09:43:15 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 10 JUN 86 09:31:49 PDT
Date: 10 Jun 86 09:31 PDT
Sender: Bobrow.pa@Xerox.COM
Subject: Re: EuLisp meeting in Bath -- Private Message
In-reply-to: MATHIS@USC-ISIF.ARPA's message of 10 Jun 86 06:56 PDT
To: MATHIS@USC-ISIF.ARPA
cc: cl-steering@SU-AI.ARPA
From: Bobrow.pa@Xerox.COM (Danny Bobrow)
Message-ID: <860610-093149-1794@Xerox>
Mailing Address
Daniel G. Bobrow
Xerox PARC
3333 Coyote Road
Palo Alto, Ca 94304
US
-- danny
∂10-Jun-86 1229 DLW@ELEPHANT-BUTTE.SCRC.Symbolics.COM Plans for Lisp Conference
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 10 Jun 86 12:29:06 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 18780; Tue 10-Jun-86 15:22:11 EDT
Date: Tue, 10 Jun 86 15:23 EDT
From: Daniel L. Weinreb <DLW@QUABBIN.SCRC.Symbolics.COM>
Subject: Plans for Lisp Conference
To: Fahlman@CMU-CS-C.ARPA, cl-steering@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12213703387.BABYL@C.CS.CMU.EDU>
Message-ID: <860610152336.0.DLW@CHICOPEE.SCRC.Symbolics.COM>
Perhaps we should have a (prepared) announcement, to the attendees,
simply explaining what the present state of things is. I'd imagine
there'd be some interested people who do not have access to the
Common-Lisp mailing list, and there isn't any good was to disseminate
status information to them. We'd have to keep it short, in order to fit
into the conference schedule, and in deference to all the functional
programming mathematicians who don't care about Common Lisp anyway.
We'd also have to be careful about what we say vis a vis European
involvement and any other such touchy subjects.
∂10-Jun-86 1256 FAHLMAN@C.CS.CMU.EDU EuLisp meeting in Bath -- Private Message
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 10 Jun 86 12:56:14 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 10 Jun 86 15:55:57-EDT
Date: Tue, 10 Jun 1986 15:55 EDT
Message-ID: <FAHLMAN.12213768800.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: MATHIS@USC-ISIF.ARPA
Cc: cl-steering@SU-AI.ARPA
Subject: EuLisp meeting in Bath -- Private Message
In-reply-to: Msg of 10 Jun 1986 09:56-EDT from MATHIS at USC-ISIF.ARPA
Bob,
I'm glad to hear that you survived the encunter at Bath. I'd be
interested in your views on whether the Eulisp group is going to hang
together once they get into hard choices. How deep are the splits?
A couple of reactions to your note:
When an ISO group is
formed, some Common Lisp decisions will have to be revisited in
forming a consensus, but don't be surprised if a lot of the
Europeans back the existing Common Lisp approach (and of course
others oppose it). The ones who wanted to change a lot of things
did not seem to have very strong support within the group (but
remember they were on their good behavior for a foreign visitor).
I've got no problem with revisiting some Common Lisp decisions. There's
never any harm in talking about things. I will have a big problem with
changing any of these decisions on purely aesthetic grounds. If the
Europeans intend to ignore the effect of changes on existing code and
implementations, then no consensus will be possible, since their goals
for this effort are fundamentally incompatible with ours.
There seems to be a real feeling of exclusion of
Europeans from the Common Lisp decision making.
The Europeans were excluded from the initial Common Lisp design process
for three reasons: (1) Lousy netmail connections to Britain at the time,
and none to the continent, (2) nobody over there expressed any interest
in participating, (3) it didn't occur to anyone in our group to seek out
possible European players. That's all history now; it can't be changed.
We should continue to empahsize that any Europeans who subscribe to our
goal of refining and standardizing the existing Common Lisp design
(perhaps by developing a multi-level spec) are more than welcome to
participate and, if it is someone with a sufficient reputation, to be on
the technical or steering committee.
We should continue to emphasize that if their goals are fundamentally
incompatible with ours, they are welcome to develop their own separate
language, as long as they don't try to stop us from doing what we need
to do.
We should be willing to talk about any changes they want to make, but
should make clear that we are not going to condier changes without
considering their cost to existing users and implementors.
What more can we do? As far as I'm concerned, Chailloux is welcome to
join the technical committee whenever he wants to, but not if he doesn't
agree with its goals.
-- Scott
∂10-Jun-86 1353 ALAN@AI.AI.MIT.EDU EuLisp meeting in Bath -- Private Message
Received: from AI.AI.MIT.EDU by SU-AI.ARPA with TCP; 10 Jun 86 13:53:42 PDT
Date: Tue, 10 Jun 86 16:54:05 EDT
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject: EuLisp meeting in Bath -- Private Message
To: MATHIS@USC-ISIF.ARPA
cc: cl-steering@SU-AI.ARPA
In-reply-to: Msg of 10 Jun 1986 06:56-PDT from MATHIS at USC-ISIF.ARPA
Message-ID: <[AI.AI.MIT.EDU].54621.860610.ALAN>
[ Cc'd to cl-steering for the benefit of anyone else who might have reason
to be collecting our addresses... ]
Alan Bawden
Massachusetts Institute of Technology
Artificial Intelligence Laboratory
Room NE43-723
Cambridge, MA 02139
(617) 253-8843
∂10-Jun-86 1907 FAHLMAN@C.CS.CMU.EDU Plans for Lisp Conference
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 10 Jun 86 19:07:04 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 10 Jun 86 22:06:38-EDT
Date: Tue, 10 Jun 1986 22:06 EDT
Message-ID: <FAHLMAN.12213836291.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "Daniel L. Weinreb" <DLW@SCRC-QUABBIN.ARPA>
Cc: cl-steering@SU-AI.ARPA
Subject: Plans for Lisp Conference
In-reply-to: Msg of 10 Jun 1986 15:23-EDT from Daniel L. Weinreb <DLW at QUABBIN.SCRC.Symbolics.COM>
Well, if it is just going to be an announcement of what has happened,
maybe we can print up a bunch of fliers to be handed out with the
registration material and not waste people's time by having someone read
this aloud. Given that things have kind of slipped and it is now rather
late, maybe we should just have whatever internal meetings we need, plus
the object-oriented meeting that Dick already proposed. But I believe
that Bob Mathis wants to do some sort of official X3J13 thing while most
of the potentially-interested parties are nearby.
-- Scott
∂11-Jun-86 1015 DLW@QUABBIN.SCRC.Symbolics.COM Plans for Lisp Conference
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 11 Jun 86 10:15:14 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 7665; Wed 11-Jun-86 13:15:01 EDT
Date: Wed, 11 Jun 86 13:16 EDT
From: Daniel L. Weinreb <DLW@QUABBIN.SCRC.Symbolics.COM>
Subject: Plans for Lisp Conference
To: Fahlman@CMU-CS-C.ARPA
cc: cl-steering@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12213836291.BABYL@C.CS.CMU.EDU>
Message-ID: <860611131606.2.DLW@CHICOPEE.SCRC.Symbolics.COM>
Yes, I think you're right. Having such a handout sounds like a good
idea. Maybe a lot of the text from it can be taken from some of the
mail that you've already written, that you distributed to Common-Lisp.
∂11-Jun-86 1141 FAHLMAN@C.CS.CMU.EDU Plans for Lisp Conference
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 11 Jun 86 11:41:40 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 11 Jun 86 14:41:18-EDT
Date: Wed, 11 Jun 1986 14:41 EDT
Message-ID: <FAHLMAN.12214017347.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "Daniel L. Weinreb" <DLW@SCRC-QUABBIN.ARPA>
Cc: cl-steering@SU-AI.ARPA
Subject: Plans for Lisp Conference
In-reply-to: Msg of 11 Jun 1986 13:16-EDT from Daniel L. Weinreb <DLW at QUABBIN.SCRC.Symbolics.COM>
OK, so far we've got an informational handout, RPG's proposed meeting
on object-oriented stuff (which he should announce ASAP), and nothing
more. We committee types can meet informally, I guess. I can see
several conference sessions I wouldn't mind skipping.
Is there anything else? A question and answer session might be more
trouble than it is worth. A formal X3J13 meeting may or may not be
required at this time.
-- Scott
∂11-Jun-86 1409 MATHIS@USC-ISIF.ARPA Plans for Lisp Conference
Received: from USC-ISIF.ARPA by SU-AI.ARPA with TCP; 11 Jun 86 14:09:42 PDT
Date: 11 Jun 1986 13:16-PDT
Sender: MATHIS@USC-ISIF.ARPA
Subject: Plans for Lisp Conference
From: MATHIS@USC-ISIF.ARPA
To: cl-steering@SU-AI.ARPA
Message-ID: <[USC-ISIF.ARPA]11-Jun-86 13:16:55.MATHIS>
There cannot be anything official for X3J13 since its first
meeting is to be September 23 and 24 in Washington. I was
planning to have a handout or some other kind of information
about that meeting. Scott and I should probably make a single
page (front and back) write-up that would give the status and
invite appropriate participation. We could talk about its
contents over the net and then Scott and I could finalize it near
the end of July. (I plan to be in Pittsburgh July 21-25.)
The EuLisp people think they are having a meeting in Boston and
when we talked about plans I got the feeling they wanted it to be
a joint meeting. If you add the Japanese, we're talking thirty
or more people -- that's too many for last minute arrangements.
If Tuesday night is available and meets most of our schedules, we
should go with it. The first decision is a time. The EuLisp
people still hadn't made their arrangements either. I'm hoping
that we will get together in small groups throughout the
conference to meet with people and explain what we are doing, but
I think we are going to need an organized group meeting too.
-- Bob
∂11-Jun-86 1410 MATHIS@USC-ISIF.ARPA EuLisp
Received: from USC-ISIF.ARPA by SU-AI.ARPA with TCP; 11 Jun 86 14:10:02 PDT
Date: 11 Jun 1986 13:39-PDT
Sender: MATHIS@USC-ISIF.ARPA
Subject: EuLisp
From: MATHIS@USC-ISIF.ARPA
To: cl-steering@SU-AI.ARPA
Message-ID: <[USC-ISIF.ARPA]11-Jun-86 13:39:33.MATHIS>
About the possibility of changing things in Common Lisp. Lots of
notations in mathematics were pretty arbitrary initially, but now
no one would think of changing them. The same applies to some
decisions in Common Lisp. (I think most of the decisions were
well founded and convincing arguments for them just need to be
reexplained; I'm talking about the weakest decisions.) At this
point the argument has to be much stronger than "this is the way
it should have been done originally" -- all these kind of
decisions have to be considered in their time context.
One topic that came up at the Bath meeting and on the net is the
relationship between NIL and () and their CAR, CDR, symbolp, etc.
[This was just a side comment when we had a break for coffee, so
I didn't get everything.] I would be at a loss to explain why
things are the way they are except to say that as people wrote
programs these were convenient ways for it to work and now that's
just the way people write programs.
I view standardization as very practical and related to the
marketplace, it is not language (re)design.
-- Bob
∂11-Jun-86 1410 MATHIS@USC-ISIF.ARPA Japanese and European participation
Received: from USC-ISIF.ARPA by SU-AI.ARPA with TCP; 11 Jun 86 14:10:25 PDT
Date: 11 Jun 1986 14:00-PDT
Sender: MATHIS@USC-ISIF.ARPA
Subject: Japanese and European participation
From: MATHIS@USC-ISIF.ARPA
To: cl-steering@SU-AI.ARPA
Message-ID: <[USC-ISIF.ARPA]11-Jun-86 14:00:24.MATHIS>
From Japan we may need to include a number of people. Ida seems
connected into the standards establishment. That is not the same
as being the most influential for Common Lisp's acceptance in a
broader community. From all our talk it seems we want Ida and
some others. I think we should invite Ida to participate and
help us find the other appropriate people.
I think we should invite Chailloux to join us too. It would be
appropriate for Scott to correspond with him or phone him to talk
about what's involved. There may be a couple of other Europeans,
but let's start with Chailloux. He'll be concerned about a
willingness to discuss the "European view" and trying to blunt US
dominance. [About US dominance -- I pointed out in a low key way
that the US was prepared to participate very actively in any ISO
language standardization effort and that having a European
convenor was not the way, necessarily, to smooth things out. I
tried to portray myself as about the most acceptable neutral
broker that they were likely to get.]
We need to do something on both the Japanese and European
participation. Since we expect most of the people we are
considering to be at the Boston meeting, we should have invited
their participation before then. We should have another round of
commenting on the net that concludes with the rest of you saying
"Bob and Scott do it."
-- Bob
∂11-Jun-86 1449 FAHLMAN@C.CS.CMU.EDU EuLisp
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 11 Jun 86 14:49:21 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 11 Jun 86 17:32:58-EDT
Date: Wed, 11 Jun 1986 17:32 EDT
Message-ID: <FAHLMAN.12214048576.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: MATHIS@USC-ISIF.ARPA
Cc: cl-steering@SU-AI.ARPA
Subject: EuLisp
In-reply-to: Msg of 11 Jun 1986 16:39-EDT from MATHIS at USC-ISIF.ARPA
Since you ask about the NIL business, the dual identity of NIL as both a
symbol and a list, and the business about CAR and CDR of NIL being legal
(both evaluate to NIL), this is a useful but terribly ugly hack. It is
useful because you can use lists as data structures and access, for
example, the CADDR of a list, even if that list has been truncated and
has no CADDR under the old rules. The problem is that once people start
using this hack, it is very hard to fix up their code not to use it.
You never are sure that you've found all the places where the assumption
comes into play.
The feature first appeared in Interlisp, I think. It was adopted in
Maclisp sometime in the mid-70's so that Interlisp code could be
imported more easily, and the convention speard from there onto the Lisp
machine (though there was a switch on the Lisp Machine to disable this
feature).
We debated for many months whether to get rid of this overloading of NIL
and to split up the concepts of NIL and the empty list into separate
items. This was one of the few decisions that almost tore the Common
Lisp effort apart. Finally, we decided that we would go with the status
quo in Maclisp, ugly as it was, so that people moving old code to Common
Lisp would not be driven crazy by subtle bugs. This was traumatic for
all of us -- the first of many victories of pragmatism over beauty. I
doubt that a proposal to re-open this question would get very far; there
has been too much blood spilled on both sides of the issue.
-- Scott
∂11-Jun-86 1551 OHLANDER@USC-ISIB.ARPA Re: Japanese and European participation
Received: from USC-ISIB.ARPA by SU-AI.ARPA with TCP; 11 Jun 86 15:51:03 PDT
Date: 11 Jun 1986 15:48-PDT
Sender: OHLANDER@USC-ISIB.ARPA
Subject: Re: Japanese and European participation
From: OHLANDER@USC-ISIB.ARPA
To: MATHIS@USC-ISIF.ARPA
Cc: cl-steering@SU-AI.ARPA
Message-ID: <[USC-ISIB.ARPA]11-Jun-86 15:48:27.OHLANDER>
In-Reply-To: <[USC-ISIF.ARPA]11-Jun-86 14:00:24.MATHIS>
Bob,
I certainly trust your and Scott's judgement. Go to it.
Ron
P.S. What are the dates of the Lisp Conference that we are all
talking about?
∂12-Jun-86 1302 FAHLMAN@C.CS.CMU.EDU Lisp Conference
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 12 Jun 86 13:02:05 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 12 Jun 86 15:38:59-EDT
Date: Thu, 12 Jun 1986 15:10 EDT
Message-ID: <FAHLMAN.12214284895.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-steering@SU-AI.ARPA
Subject: Lisp Conference
So what I seem to be hearing is the following:
1. We put out an announcement letter and make it available at conference
registration. This will describe how to participate in X3J13, among
other things. Mathis and I will work on this.
2. RPG will announce the Object-Oriented session once he has worked out
the details.
3. We will find some time for all of us (at least, all who make it to
Boston) to get together. Try to keep Tuesday night open.
4. We will talk with the Eulisp people and see if they want to have a
joint meeting.
5. That's all. No other public activities related to Common Lisp.
Right?
-- Scott
∂12-Jun-86 1515 DLW@ELEPHANT-BUTTE.SCRC.Symbolics.COM EuLisp
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 12 Jun 86 15:15:03 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 20854; Thu 12-Jun-86 17:32:28 EDT
Date: Thu, 12 Jun 86 17:34 EDT
From: Daniel L. Weinreb <DLW@QUABBIN.SCRC.Symbolics.COM>
Subject: EuLisp
To: Fahlman@CMU-CS-C.ARPA, MATHIS@USC-ISIF.ARPA
cc: cl-steering@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12214048576.BABYL@C.CS.CMU.EDU>
Message-ID: <860612173406.7.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: Wed, 11 Jun 1986 17:32 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
I doubt that a proposal to re-open this question would get very far; there
has been too much blood spilled on both sides of the issue.
Right. It's sort of a shame that so much of the recent Common-Lisp mail
has been proposals to reopen all kinds of questions. It's gotten to the
point where it's hard to find the interesting messages among all the
"Gee, why is Common Lisp like this, it really ought to be like that"
mail. I don't know what to do about this.
∂12-Jun-86 1651 FAHLMAN@C.CS.CMU.EDU EuLisp
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 12 Jun 86 16:51:31 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 12 Jun 86 19:51:03-EDT
Date: Thu, 12 Jun 1986 19:51 EDT
Message-ID: <FAHLMAN.12214335899.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "Daniel L. Weinreb" <DLW@SCRC-QUABBIN.ARPA>
Cc: cl-steering@SU-AI.ARPA
Subject: EuLisp
In-reply-to: Msg of 12 Jun 1986 17:34-EDT from Daniel L. Weinreb <DLW at QUABBIN.SCRC.Symbolics.COM>
Right. It's sort of a shame that so much of the recent Common-Lisp mail
has been proposals to reopen all kinds of questions. It's gotten to the
point where it's hard to find the interesting messages among all the
"Gee, why is Common Lisp like this, it really ought to be like that"
mail. I don't know what to do about this.
All this will go away when we start making actual decisions on actual
issues. Idle speculation like this will get shot down early by the moderator
(me), unless the person in question makes clear that it is discussion
for the future and not aimed at the current standardization effort.
I've been trying to get everything set so that I can start putting major
amounts of time into this, but I've had a few higher-priority things to
clean up first (e.g. CMU's DARPA Basic Research proposal isn't quite
finalized yet, though it's getting very close).
Anyway, I'll start cracking the whip or pounding on the hull or whatever
I'm supposed to do RSN (Real Soon Now).
-- Scott
∂12-Jun-86 2234 FAHLMAN@C.CS.CMU.EDU [a37078%ccut.u-tokyo.junet%utokyo-relay.csnet: Common Lisp Meeting]
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 12 Jun 86 22:34:14 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 13 Jun 86 01:34:08-EDT
Date: Fri, 13 Jun 1986 01:34 EDT
Message-ID: <FAHLMAN.12214398356.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-steering@SU-AI.ARPA
Subject: [a37078%ccut.u-tokyo.junet%utokyo-relay.csnet: Common Lisp Meeting]
I just got this from Ida. My answer to him follows...
Date: Fri, 13 Jun 86 12:13:18+0900
From: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet at CSNET-RELAY.ARPA>
To: fahlman, ida at UTOKYO-RELAY.CSNET
Re: Common Lisp Meeting
Dear Prof. Fahlman,
I will go to USA to attend Lisp conf at MIT, and to attend AAAI86.
I guess there will be a Common Lisp Meeting.
I want to attend it.
Furthermore, I want to present a short speech on the meeting about the current
status of the Common Lisp related activity in Japan.
I feel I have a resposibility to play a role of the interface between USA and Japan for the matter.
I do not know who is the best person to send this mail,
but I am sending it to you only.
Because I think you are one of the best person of Common Lisp with university
background.
If will be granted, I have the following item to speak.
1) What is our subsetting. We can distribute the copies at the speech.
2) What is our on-going decision on Kanji and string/character extension.
3) What is the current status in japan.
Last fall 1985, we made a questionnare about the CommonLisp/AI, including
a question like what language do you use, what is you opinion about Common lisp,
what langauge features are good in Common Lisp,...
We have formed AI Association from april.
We are now starting a working committee for JIS which is correspondent to
the action of ISO.
And Other things.
Can I have your frank opinion or suggestion ?
Should I ask it to other person ?
Or, I can not have a speech ?
Thank you.
Masayuki Ida
ida%utokyo-relay.csnet@csnet-relay.arpa
(I can also get a mail through this return path)
∂12-Jun-86 2236 FAHLMAN@C.CS.CMU.EDU [Fahlman: Common Lisp Meeting]
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 12 Jun 86 22:35:47 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 13 Jun 86 01:35:41-EDT
Date: Fri, 13 Jun 1986 01:35 EDT
Message-ID: <FAHLMAN.12214398638.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-steering@SU-AI.ARPA
Subject: [Fahlman: Common Lisp Meeting]
Date: Friday, 13 June 1986 01:32-EDT
From: Scott E. Fahlman <Fahlman>
To: ida%utokyo-relay.csnet at CSNET-RELAY.ARPA
cc: fahlman
Re: Common Lisp Meeting
Professor Ida,
I am pleased to hear that you will be at the Lisp Conference. Those of us on
the technical and steering committees in the U.S. very much want to meet
with you to discuss what sort of formal liaison should exist between the
Japanese Common Lisp community and our group. We welcome Japanese
participation in the design discussions and hope that there will be more
of it, but we also want to include one or more Japanese members on our
technical and steering committees, or set up parallel committees in the
U.S. and Japan that would work closely together, or something like that.
We have talked to a few of our colleagues in Japan about how to proceed
with this. Some have suggested that we should invite your JEIDA
committee to nominate someone to join our committee. Others have felt
that we must carefully observe the proper formal procedures in dealing
with the Japanese and have said that it is important to involve some
very senior people in this process, even if they do not have much time
or energy to spend on Common Lisp. We want to make it clear that we
view Japan as a very important partner in the standardization effort,
but we don't know what the proper formal steps are or what groups should
be consulted. I would very much appreciate hearing your views on how we
should handle this. Is this new JIS committee on Lisp the right group
for us to deal with?
On the issue of a general Common Lisp meeting at the Lisp Conference, I
don't think there will be one. We got started rather late in thinking
about this, and now it is rather late to set up such a meeting. There
is no time left during the conference, so a meeting would have to be the
day before the conference or the day after. Many people already have
travel plans and would be unable to stay for an extra day. So I am
afraid that there will not be an opportunity for you to present your
three topics to a general Common Lisp meeting.
Dick Gabriel is about to announce that there will be an open meeting on
Wednesday afternoon (August 6), after the Lisp Conference is over, to
discuss Object-Oriented programming in Common Lisp. The technical and
steering committees will be meeting at some time during the conference,
perhaps on Tuesday night, and I am sure that you would be welcome to
join us in this meeting and to tell us about the situation in Japan.
The Eulisp group plans to meet at some time during the Boston conference
as well, and many of us will attend that meeting if they allow us to; we
hope that we can make peace with those people without agreeing to let
them put radical changes into Common Lisp. The first formal meeting of
the ANSI committee, X3J13, will be in Washington on September 23 and 24.
The rules of ANSI make it impossible for this to occur at the time of
the Lisp Conference. We will be handing out a printed announcement with
the Lisp Conference registration materials that will describe what has
been done on standardization in the U.S. and that invites everyone to
participate in X3J13 if they want to.
In my view, complex issues like subsetting and extended character sets
are best handled by netmail. I plan to start detailed technical
discussions on a number of issues very soon, and I hope that we work out
a detailed agreement on how to handle this the Boston meeting. Some
discussion has occurred already, as you have seen, though nothing has
been settled. Since this extension exists mostly to accommodate Kanji,
we certainly won't adopt anything that the Japanese Lisp community
doesn't like.
Best regards,
Scott Fahlman
∂13-Jun-86 1007 RPG Use of Lucid Manual
To: cl-steering@SU-AI.ARPA
Ok, our lawyers have looked into the situation, and there is
no simple solution until we start to negotiate with ANSI.
That is, there seems to be no default way to set up copyright
protection for Lucid that is reasonble for the committee and suitable for
Lucid. One way to proceed is for Lucid's lawyers to draw up
an agreement that the committee signs and which does the proper
protection. The protection clause will be tough - Lucid will be
able to veto the document if it is felt that it jeopardizes the
Lucid copyright.
On the other hand, I have a large say in what Lucid vetoes. How shall
we proceed?
-rpg-
∂13-Jun-86 1121 FAHLMAN@C.CS.CMU.EDU Use of Lucid Manual
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 13 Jun 86 11:21:34 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 13 Jun 86 14:16:01-EDT
Date: Fri, 13 Jun 1986 14:15 EDT
Message-ID: <FAHLMAN.12214537051.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Dick Gabriel <RPG@SU-AI.ARPA>
Cc: cl-steering@SU-AI.ARPA
Subject: Use of Lucid Manual
In-reply-to: Msg of 13 Jun 1986 13:07-EDT from Dick Gabriel <RPG at SU-AI.ARPA>
Can you show us the exact language of the agreement that your lawyers
want?
I've been reluctantly coming around to the view that the easiest way to
proceed is for me to write a new specificaton document from scratch.
I'd rather spend time writing than hassling with lawyers. This document
would be copyrighted by me personally, with an agreement (informal or in
writing, whatever people are happy with) that I will try to make it
reflect precisely the decisions of the technical committee and that I
will handle the rights to this work in accordance with the wishes of the
combined technical and steering committees. We could decide to turn the
copyright over to ANSI or whatever later on. I would not be interested
in getting any money out of this, though if I do the work I would like
to keep my name on the thing in some prominent position -- it helps my
employers at CMU to appreciate that I'm doing SOMETHING with my time.
Given the amount of work this would entail, the document would be as
terse, precise, and technical as I can make it. There would very
definitely be a place for a friendlier manual, perhaps a second edition
of Steele if he wants to create one, but we would all agree that this
new thing is the definitive spec.
To make the MIT contingent happy, it would be done initially in vanilla
80-column ASCII, though we'd probably convert it to TeX at the end.
I'd still prefer to start with Steele's manual or with Lucid's, but that
is looking less and less like a live option.
-- Scott
∂13-Jun-86 2149 FAHLMAN@C.CS.CMU.EDU [a37078%ccut.u-tokyo.junet%utokyo-relay.csnet: Lisp standardization]
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 13 Jun 86 21:49:13 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 14 Jun 86 00:49:10-EDT
Date: Sat, 14 Jun 1986 00:49 EDT
Message-ID: <FAHLMAN.12214652306.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-steering@SU-AI.ARPA
Subject: [a37078%ccut.u-tokyo.junet%utokyo-relay.csnet: Lisp standardization]
Here is Ida's response to the note I sent him. It is a bit hard to
parse, as you will see, but it does contain lots of good information
about the structure of the effort in Japan. I'm still trying to sort it
all out, but it looks like Ida is certainly one of the people we want,
maybe on the steering committee as he suggests. Suggestions are welcome
at this point.
-- Scott
---------------------------------------------------------------------------
Date: Sat, 14 Jun 86 11:57:40+0900
From: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet at CSNET-RELAY.ARPA>
To: fahlman, ida at UTOKYO-RELAY.CSNET
Re: Lisp standardization
Professor Fahlman,
Thank you for your quick responce to my mail.
Here are my views/opinions/descriptions about the things you wrote to me.
1) My visit to Lisp conference and AAAI conference.
I will visit USA with several persons of our committee as a team.
Scheduled dates are one week stay at Boston from Aug.3 to 10,
and another one week stay at AAAI site, roughly.
1') I will join you at the meeting you suggested. and I am pleased to know
I will be welcomed to discuss and tell the situation in japan.
1'') As I stated in 1), I will be with several colleagues at hotel.
We will have a meeting at the hotel.
So, I want to arrange an invitation to our meeting.
Can you spare your time to join us at Boston ?
2)General steps toward the standardization of computer languages in japan.
There is only one committee for MITI whose name is JIS programming language
standardization or so. All the computer languages are defined by this
committee. But the actual working is not carried by the committee, like
SC22 forms WG for each language. The membership of this top committee
are not opened and I am not the member of this top committee.
I think almost all the members are very senior persons.
From my experinece and my knowledge, the standardization is initially
directed by MITI. This task force is undertaken by Jeida or IPSJ.
After the actual works by Jeida or IPSJ finish, MITI calls the members for
the top JIS committee and ask them to guarantee it. The draft which appear to
the top committee is not actually discused, when the language spec is parallely
defined to ANSI.
Jeida standardization team is carried by Prof. Yoneda (u-tokyo).
IPSJ standardization team is carried by prof. Nakata (u-Tsukuba).
Prof. Nakata is an official member of ISO TC22 as a representative of Japan.
(he gave me a copy of Bob Mathis's proposal of Ad Hoc Group on the preparation
of NWI on Prolog and LISP to ISO/TC97/SC22)
The documents appeared at ISO are send to MITI, then forwarded to several
persons, including Prof. Nakata at least.
He has, currently, a role to catch up the standardization of Fortran, Cobol,...
On the other hand, Prof. Yoneda has a role to establish a standard
for more "fresh" languages, like C, Ada, Lisp,...
MITI select and decide which team is more suitable for any computer languages.
Last tuesday, June 10, I was called by the staff of Prof. Yoneda's committee
at Jeida.
He told me that MITI suggest to start the working committee for Lisp
standardization, and that the committee is under Prof. Yoneda's committee
and I should be the chair of the JIS committee also.
Then I will start the working committee to make a JIS draft with 13 members.
the number of members is prior assigned and given to me.
The scheduled dates of this year is one-a-two-month.
The first meeting will be in July.
Prof.Yoneda (and Prof. Nakata) is very senior person.
I think the formal process in Japan is going just like you mentioned.
I mean I agree your suggestion of your mail. i.e. ANY offical activities for
standardization in Japan need senior persons who have responsibilities to
totally control the whole process, even though he has only a basic knowledge
about the language, and he can not understand the details
or he have no time to spare to learn the language details.
This JIS committee is different from the Common Lisp committee I have been
talking about. But, they are all in Jeida.
And they will be gathered to form a one large committee, I think.
I think it is very usual to form a JIS working committee which is parallel to
ANSI/ISO committee and the JIS committee will communicate with ANSI committee.
3) Member to ANSI committee from Japan
I think the chair of the JIS committee should be a member of ANSI committee for
this case. The reason is to avoid the separation of two standardizations
and to keep ANSI committee can totally control the whole thing.
I think the latter property is important, considering an unfortunate condition.
Further, I even think it might be the best that someone in ANSI committee
will attend Jeida committee.
My current Jeida Common Lisp committee have totaly , over 40 members from
26 different organizations.
They have more knowledge and skill than before.
But KCL persons have a great role and a great infruence to Common Lisp
in Japan. So, technically, Mr. Yuasa or Mr. Hagiya is the best person to
technical committee. I think I am the next to them for the technical matter.
For steering and standardization, I think I am the best person to join.
Last april AI Association of Japan was formed. in my view, this organization
has a relation to Common Lisp as a user organization.
There is also a standardization committee. I was asked by them to be a chair
for the standardization committee. But it is not formed yet. I do not know
whether this group will survive or no now. But as the result of our
questionnair shows, AI application in Japan is 60% based on Lisp or more,
and the most actually used Common Lisp implemetation is VAXlisp,then
Symbolics Lisp, then KCL. We should watch what the user society want.
4) Object oriented facility for Common Lisp.
I have been following CommonLoops.
Last year, before PCL appeared, I designed an interpretation of CommonLoops
and presented a paper on it.
Last Feb, I stayed at Xerox PARC for one week.
I have experienced and somewhat assisted them to improve PCL.
Xerox lawyer permitted me to carry back PCL sources.
Now, I play a role of re-distributor of PCL in Japan.
I am now researching with PCL.
Since 1984 fall, I followed the discussion of o-o-bboard with the permission of
Ken Kahn. Since last summer, I directed some members of my committee to catch
up which is the best for Common Lisp among CommonLoops, objectLisp,...
I think we, japanese are ready to accept the function call generalization
of message sending and defstruct based flavor and so on.
Several researchers in japan, to my surprise, already presented papers for
present Prolog like facility upon CommonLoops-like object oriented facility.
5) Subset.
Personally, I have an opinion that there should be two levels of Lisp
language specification.
Our subset working group will present their polish up of my proposal at July
8th in Japan. This group will make a pilot version of the subset.
This subset can not self-compile itself.
BUt this subset is intended to be fully compatible to the super.
I have several friends in Gold Hill computers.
Last March, I presented our subset draft to Dr. Jerry Barber at his office.
And discussed with him for one or two hours.
I also informed Professor Pat. Winston at his office.
I hope we can make peace with them.
As to EuLisp, here is Dr. Jean Peer Briot from Paris who is now visiting
Japan as a visiting scientist, who has a relation to Chaillox of LeLisp.
I was phoned by him and we met in tokyo.
He told me that he was directed to meet me by Chaillox.
I gave several staffs to him.
6) kanji and character/string
We will polish up our discussion.
I formed a working group for it. members are from ETL, HItachi, NEC, Fujitsu,
Xerox, Symbolics, I and some othe rpersons.
I think we can have some more concrete opinion before I will goto USA.
I do not think it will be integrated into the one and only one opinion
immediately. I think it may need a voting or take a year or so.
Masayuki Ida
∂14-Jun-86 0655 MATHIS@USC-ISIF.ARPA EuLisp and Boston
Received: from USC-ISIF.ARPA by SU-AI.ARPA with TCP; 14 Jun 86 06:55:01 PDT
Date: 14 Jun 1986 06:53-PDT
Sender: MATHIS@USC-ISIF.ARPA
Subject: EuLisp and Boston
Subject: [ Fitch@Cs.Ucl.AC.UK: Standards meeting at Boston]
From: MATHIS@USC-ISIF.ARPA
To: cl-steering@SU-AI.ARPA
Message-ID: <[USC-ISIF.ARPA]14-Jun-86 06:53:53.MATHIS>
For your information
Begin forwarded message
Received: FROM CS.UCL.AC.UK BY USC-ISIF.ARPA WITH TCP ; 12 Jun 86 11:15:22 PDT
Date: Wed, 11 Jun 86 22:53:22 BST
From: Fitch@Cs.Ucl.AC.UK
To: rhh%mit-mc.arpa@Cs.Ucl.AC.UK
Cc: mathis@usc-isif.arpa, bond!m42!eulisp%ux63.bath.ac.uk@Cs.Ucl.AC.UK
Subject: Standards meeting at Boston
Return-Path: <Fitch@Cs.Ucl.AC.UK>
I heard recently from Bob Mathis that he had contacted you about the
possiblity of holding a meeting during the LISP conference about LISP
standardisation. As you might have heard, there is also considerable
interest in this matter in Europe too, such that there is a group of
people meeting monthly to develop a standards proposal. That european
group generally meets on the first Monday of every month, which in August
coincides with the first day of the LISP conference, therefore it was
agreed that we would try to hold the August meeting of the EuLISP committee
during the Boston meeting. We also feel it is particularly important that
there should be one such standards meeting and so we would like the
general discussion on standards and our monthly meeting (at least those
parts of it that are not too boring and organisational) to be held
jointly. Will it be possible for you to arrange a room for this?
Thanks.
--Julian (Padget)
--------------------
End forwarded message
∂14-Jun-86 1250 FAHLMAN@C.CS.CMU.EDU Standards
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 14 Jun 86 12:49:58 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 14 Jun 86 15:49:55-EDT
Date: Sat, 14 Jun 1986 15:49 EDT
Message-ID: <FAHLMAN.12214816283.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Mathis@USC-ISIF.ARPA
Cc: cl-steering@SU-AI.ARPA
Subject: Standards
Bob,
I recieved your packet of material obtained from the Eulisp group.
Thanks.
One point they make is that the creation of a separate Common Lisp
committee under ANSI is in violation of ISO rules and that the British
stadards organization is upset about this. Is this true? Is it
serious? I have found it reassuring to believe that, whatever stupid
thing ISO does, we would at least have an ANSI standard for Common Lisp.
If they can prevent that, while seizing control of the ISO machinery,
then we're back to having a completely informal standard for Common Lisp
that everyone follows, while there is an official ISO standard that is
supported by six people (and 20 countries) worldwide.
Obviously there are a few people in that group have are personally quite
bitter about Common Lisp passing them by. Stoyan, Padgett, and Fitch, I
believe. There were some beautiful examples of venomous writing in
their internal document, all aimed at Common Lisp. They make excellent
use of the Brooks and Gabriel critique as a weapon against us. I don't
know what one does to assuage such intense feelings, except to
reciprocate with as much reasonableness as we can muster and hope that
they dissipate over a period of a year or two.
They repeatedly level three criticisms at the existing Common Lisp:
1. It is big.
2. The current spec is imprecise.
3. It ignores all Lisp developments outside the Maclisp world.
Their solutions:
1. Multi-level definition.
2. Level-0 is to be specified by formal means, probably denotational
semantics, and the higher levels are somehow supposed to inherit
precision from that.
3. Encouraging a more widespread discussion of of Lisp standardization.
My reactions:
1. Yes, it is big. This isn't a problem, in my view. If it were
a problem, it should be solved by one or more true subsets of Common
Lisp, rather than by starting over.
2. Their solution won't work, or at least it is something that has never
worked in the past. The best we can do is to take a
well-tested, widely used Lisp and clean up the problems that
people have discovered.
3. It is demonstrably false that Common Lisp ignored everything outside
the Maclisp tradition. Steele was the co-inventor of Scheme, and we
got input from many other groups. What they are really saying is
"WE weren't consulted about this." That is both true and
regrettable, but throwing away Common Lisp and starting over is
hardly the appropriate remedy, now that Common Lisp has become a de
facto standard supported by every company that matters.
We should have a joint meeting with the Eulisp people in Boston to see
if there is any acceptable way to settle this.
-- Scott
∂16-Jun-86 1006 RPG Various Issues
To: cl-steering@SU-AI.ARPA
I have various comments to make.
First, the Brooks/Gabriel critique is not a devastating problem, because
Brooks is the fourth largest founder of Lucid and Gabriel the largest;
Lucid supplies Common Lisp. As a pure language design, Common Lisp
suffers some, and I believe that our criticisms, in that paper, are
still correct. I think we can repair some of the problems in
Common Lisp easily.
Second, we have yet to begin to attack the European commercial concerns,
most of whom are moving towards Common Lisp. I just received a set
of French articles about Common Lisp and its adoption by French
companies. I doubt that these companies want to have adopted Common Lisp
only to have to abandon it because their countrymen want to have fun.
Third, we cannot ignore the root causes for their standardization effort.
They were passed by; there is fame in being on a standards organization,
even an ad hoc one; various of the people feel they have been screwed -
for example, Padgett submitted a paper to the last L & FP conference,
which we rejected it as not discussing a well-though-out or important
idea, and POPL accepted the paper; and there is national pride involved.
Fourth, I don't see anything wrong with having a layered standard. I would
like to guarantee that the level n version is implementable by the level-0
version, and I'm not sure they've got that right yet.
Fifth, do we know the status of the the-ANSI-route-is-illegal objection?
Mathis should figure this out soon.
Sixth, I'm nervous about having exactly one of us hold the copyright to the
new document - that's how we got into trouble originally. Everyone here,
I'm sure, will agree that Steele has the highest standards, but he
made a mistake-in-retrospect. How can we be sure we don't do that again
unless the copyright is committee-wide?
Seventh, I sent a note to Fitch/Padgett regarding a face-to-face
meeting at the L & FP conference.
-rpg-
∂16-Jun-86 1140 JMC further development of Lisp
To: cl-steering@SU-AI.ARPA
Common Lisp needs to be a standard, and effecting this requires making
only clarifying changes and fixing the worst bugs. However, Lisp isn't
perfect and should be developed further. This is being done by individual
projects, and ideas are being exchanged through the public literature. It
seems to me that much of the European concern (is it called Eulisp?) is
oriented towards a collective effort at a futuristic Lisp. Perhaps some
of the Common Lisp people would be interested in taking part in such an
effort in addition to the Common Lisp standardization. On the other hand,
it may be that the best way to make advances for the next n years is to
avoid any official effort and await the results of the individual
projects. It may even be that the official standardization efforts for
Common Lisp are redundant; perhaps a de facto standard is good enough.
I don't know the answer to either question, and I don't even know how to
get an answer.
∂16-Jun-86 1303 FAHLMAN@C.CS.CMU.EDU Various Issues
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 16 Jun 86 13:03:03 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 16 Jun 86 16:02:44-EDT
Date: Mon, 16 Jun 1986 16:02 EDT
Message-ID: <FAHLMAN.12215342906.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Dick Gabriel <RPG@SU-AI.ARPA>
Cc: cl-steering@SU-AI.ARPA
Subject: Various Issues
First, the Brooks/Gabriel critique is not a devastating problem...
I agree that your subsequent activities have shown that you two haven't
given up on Common Lisp. I was merely pointing out that the EuLisp
people are finding lots of ammunition in that article for THEIR view
that throwing out Common Lisp and starting over is the right thing to do.
Second, we have yet to begin to attack the European commercial concerns,
most of whom are moving towards Common Lisp.
Good point. I wonder if there's anything we can do to encourage the
pro-Common Lisp Europeans to get involved in standardization efforts in
their respective countries. We could invite some of them to work with
our committee, but that would really infuriate the EuLisp people -- sort
of like giving U.S. aid to the contras.
Third, we cannot ignore the root causes for their standardization effort.
They were passed by; there is fame in being on a standards organization,
even an ad hoc one; various of the people feel they have been screwed -
for example, Padgett submitted a paper to the last L & FP conference,
which we rejected it as not discussing a well-though-out or important
idea, and POPL accepted the paper; and there is national pride involved.
Also a good point. It would be nice to get any or all of these people
involved with the Common Lisp standardization effort now (from which
they would reap appropriate fame), but now that they are all on record as
opposing the concept of standardizing Common Lisp, I don't see them
agreeing to this unless we tell them that they can change whatever they
want.
Fourth, I don't see anything wrong with having a layered standard. I would
like to guarantee that the level n version is implementable by the level-0
version, and I'm not sure they've got that right yet.
I've got no problem with this either, except that it is very easy to
slip in little changes in level 0 that require a total rewrite of the
Common Lisp level. The EuLisp group is making no effort to have the
highest level be the same as the current Common Lisp, and are changing
things like NIL.
Fifth, do we know the status of the the-ANSI-route-is-illegal objection?
Mathis should figure this out soon.
Sixth, I'm nervous about having exactly one of us hold the copyright to the
new document - that's how we got into trouble originally...
If Steele still held the copyright, I don't think there would be a
problem. The problem is that is was assigned to Digital Press, and at
the time several of us assented to this decision, so it was a group
mistake. If I were to hold the copyright, I would guarantee to handle
it however the combined committees tell me to. We still might make
another group mistake, but there's no more danger of that than if we
hold the copyright jointly. Still, it is cleaner to follow McCarthy's
suggestion that we all hold the copyright as an informal partnership.
If someone can work out the legalities, I'm happy to go that way, but I
don't think we can delay any longer. I propose to start building up a
document under my copyright and to assign it to this partnership when
and if we understand how to do that. I'm certainly open to alternative
suggestions.
-- Scott
∂16-Jun-86 1634 DLW@QUABBIN.SCRC.Symbolics.COM Various Issues
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 16 Jun 86 16:34:39 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 9442; Mon 16-Jun-86 19:35:02 EDT
Date: Mon, 16 Jun 86 19:35 EDT
From: Daniel L. Weinreb <DLW@QUABBIN.SCRC.Symbolics.COM>
Subject: Various Issues
To: Fahlman@CMU-CS-C.ARPA, RPG@SU-AI.ARPA
cc: cl-steering@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12215342906.BABYL@C.CS.CMU.EDU>
Message-ID: <860616193558.3.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: Mon, 16 Jun 1986 16:02 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
First, the Brooks/Gabriel critique is not a devastating problem...
I agree that your subsequent activities have shown that you two haven't
given up on Common Lisp. I was merely pointing out that the EuLisp
people are finding lots of ammunition in that article for THEIR view
that throwing out Common Lisp and starting over is the right thing to do.
In my opinion, their problem is that they think that "designing a new
language" and "establishing a new language ISO standard" are activities
that should be done simultaneously. It's too bad they can't see this.
∂16-Jun-86 1942 FAHLMAN@C.CS.CMU.EDU further development of Lisp
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 16 Jun 86 19:42:04 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 16 Jun 86 22:41:59-EDT
Date: Mon, 16 Jun 1986 22:41 EDT
Message-ID: <FAHLMAN.12215415589.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: John McCarthy <JMC@SU-AI.ARPA>
Cc: cl-steering@SU-AI.ARPA
Subject: further development of Lisp
In-reply-to: Msg of 16 Jun 1986 14:40-EDT from John McCarthy <JMC at SU-AI.ARPA>
I agree that standardizing Common Lisp and developing new ideas for Lisp
are distinct activities, both worthy. I wish the Europeans agreed. As
Weinreb has pointed out, they seem to muddle together the ideas of
"standard" and "perfect".
I think that their effort would go much better if they were to forget
all about the existence of Common Lisp. They seem to want to build on
Scheme, but are making some concessions in the direction of Common Lisp
(but not the right ones from our point of view).
I think that the Europeans are afraid that they will come up with a
shiny new Lisp, and that this will be ignored by everyone else. They're
probably right. So the plan is to make it THE Lisp standard at ISO, and
thereby to force everyone to use their dialect. Standards organizations
don't work this way -- unpopular standards have always been ignored.
I think that the creation of an official standard for Common Lisp is
important (though not essential). We need some mechanism for resolving
the ambiguities in CLtL and for fixing a few glaring problems, and a
standards effort is one good way of organizing this. If everyone
beleives that we're headed toward a standard and then we get blocked at
the end, I think that people will tend to follow what we've done.
-- Scott
∂16-Jun-86 1944 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM Various Issues
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 16 Jun 86 19:43:59 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 23099; Mon 16-Jun-86 22:43:17 EDT
Date: Mon, 16 Jun 86 22:42 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Various Issues
To: cl-steering@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12215342906.BABYL@C.CS.CMU.EDU>
Message-ID: <860616224236.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 16 Jun 1986 16:02 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
....The EuLisp group is making no effort to have the
highest level be the same as the current Common Lisp, and are changing
things like NIL....
At this point I think we shouldn't assume that what Stoyan's incoherent
document says is what the Eulisp group is doing, especially after Bob
Mathis's report that there was substantial disagreement within the
committee. We may as well give them the benefit of the doubt, for the
moment. I prefer to be selective about how I read their Lisp Conference
paper, at least in public, and put more weight on the conciliatory language
in there than on the suggested changes. The proposed changes in that paper
are obviously half-baked, I think they even admit that in the paper, and
also obviously were written by people with a very shallow understanding of
Common Lisp. I also found it interesting that you have to read that paper
very closely to realize that they are proposing to have a single name space
for functions and variables, rather than Common Lisp's separate name
spaces. Possibly this means that the authors of the paper didn't agree on
this point, so they toned it way down.
Perhaps we can educate them away from certain positions that are not in
fact "in the spirit of Common Lisp", while at the same time benefiting from
their goals (which I think are laudable). Of course, maybe I'm just being
naive and playing right into the bastards' hands. I think reversing the
decisions on NIL or FUNCTION that we arrived at rather painfully does not
serve any of their (stated!) goals in any significant way. Certainly the
reaction of the vast majority of my users would be "I don't care one whit
whether the empty list is a symbol or not, I just want my expert systems or
power plant simulations or speech understanding systems or whatever to
work. Will you Lisp guys -please- make up your minds on one language and
stick to it, so I don't have to keep converting my software!"
On the subject of reaping fame: Is there significant fame to be reaped by
redirecting a bunch of Lisp hackers who are throwing themselves over a
cliff by ignoring formal descriptions and layered specifications, and
forcing them to tread the Right Path?
∂17-Jun-86 0859 DLW@ELEPHANT-BUTTE.SCRC.Symbolics.COM further development of Lisp
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 17 Jun 86 08:58:53 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 23317; Tue 17-Jun-86 10:59:14 EDT
Date: Tue, 17 Jun 86 11:01 EDT
From: Daniel L. Weinreb <DLW@QUABBIN.SCRC.Symbolics.COM>
Subject: further development of Lisp
To: Fahlman@CMU-CS-C.ARPA, JMC@SU-AI.ARPA
cc: cl-steering@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12215415589.BABYL@C.CS.CMU.EDU>
Message-ID: <860617110152.9.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: Mon, 16 Jun 1986 22:41 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
I think that the creation of an official standard for Common Lisp is
important (though not essential). We need some mechanism for resolving
the ambiguities in CLtL and for fixing a few glaring problems, and a
standards effort is one good way of organizing this. If everyone
beleives that we're headed toward a standard and then we get blocked at
the end, I think that people will tend to follow what we've done.
I agree. Scott, I am extremely encouraged to see how much initiative
you're taking and how much work you're putting in. I'd really hate to
see you discouraged or exhausted by political battles within ISO. In
fact, anticipation of such problems is exactly the reason we originally
felt we should not get involved with ISO in the first place. I would
much rather see your energy, skill, and experience directed towards
pulling together the mechanisms for resolving ambiguities in CLtL, than
see you get so put off by all the politics that you would rather have
nothing to do with CL any more! So, I respectfully recommend that you
give the ISO/Europe problem a reasonable amount of attention but be
careful not to let it get overwhelming.
In fact, if a good, working process emerges for fixing the ambiguities,
that will further increase people's confidence in the CL standard. In
the long run, that kind of confidence will lead to the kind of
popularity that will make the standard a success.
∂17-Jun-86 1055 OHLANDER@USC-ISIB.ARPA Re: Various Issues
Received: from USC-ISIB.ARPA by SU-AI.ARPA with TCP; 17 Jun 86 10:55:33 PDT
Date: 17 Jun 1986 10:44-PDT
Sender: OHLANDER@USC-ISIB.ARPA
Subject: Re: Various Issues
From: OHLANDER@USC-ISIB.ARPA
To: cl-steering@SU-AI.ARPA
Message-ID: <[USC-ISIB.ARPA]17-Jun-86 10:44:08.OHLANDER>
In-Reply-To: <860616224236.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Given that the first stages of CL development is past history, I still want to
make a few comments to set the record straight. I think you who are the
primary architects of CL are chastizing yourselves too much concerning your
failure to get other countries (or even other domestic parties) involved. I
submit that the only reason that CL happened in the first place was your
dedication to an important goal and some support from DARPA. I don't think
that there were many others out there who were willing to put in the sheer
hard work that you were to get the job done. I don't think that the EuLisp
people were organized enough at that time to contribute in a major,
constructive way and I believe there would have been serious danger of
religious wars so that CL may have never happened. I further believe that the
very existence of CL has served to polarize views and motivate others to
develop some standard. Without CL we would probably still see the general
flailing around that went on for many years. While at DARPA, I had the chance
to observe and gather responses from the rest of the community. My
recollections from that period are that, in general, the rest of the Lisp
world had some interest in what was going on in CL but that many never felt
very strongly about what was happening. Of course, this all changed when CL
became real, DARPA put its weight behind it, and vendors started to adopt it
in great numbers. Now everyone feels they should have been a part of it.
Be that as it may, I do think it is important to get CL established as a
standard. As others of you have pointed out, the fact that we are doing so
will motivate vendors to adopt CL. From what has been said, I believe there
is probably a very good chance to get the Japanese on board. They are likely
to regard a standard as a very important issue and one they want to be
involved with. I also think that we should involve the EuLisp in the
standardization process if we can get them to contribute in a constructive
way. Perhaps, if they see the Japanese cooperating, the EuLisp people will be
motivated to do so also.
We need to press on in the most effective way possible to get the
standardization process going. This may take the form of pushing very hard on
the ANSI side of things. If we have that standardization completed, we may be
in a much stronger position vis-a-vis ISO standardization. (Bob can you give
us some opinion on this?)
I wish to second Scott's opinion concerning a copyright. We should get that
done as soon as possible. I think it would be best to have it vested in some
CL organization or partnership of interested parties, but that would require
that some group be formalized. I will talk to the lawyers here to see what it
takes to make this happen. In the meantime, I support Scott's position of
pressing on and getting the copyright in his name. It can be reassigned at a
later date to some CL official body.
I also want to second Dan's observation concerning the amount of work that
Scott is putting into this effort. I welcome his leadership in this matter
and I believe we owe him some gratitude for taking on the time-consuming task
of seeing that we move forward.
Ron
∂17-Jun-86 1831 FAHLMAN@C.CS.CMU.EDU Technical progress
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 17 Jun 86 18:30:56 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 17 Jun 86 21:30:40-EDT
Date: Tue, 17 Jun 1986 21:30 EDT
Message-ID: <FAHLMAN.12215664748.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-steering@SU-AI.ARPA
Subject: Technical progress
In-reply-to: Msg of 17 Jun 1986 13:44-EDT from OHLANDER at USC-ISIB.ARPA
Thanks to Dan and Ron for the encouragement. Now we must get on with
the real work. The better job we do on the technical side, the less any
of this political stuff will matter.
I'm going to make two files, one for issues to be resolved and one for
decisions of the technical committee. As problems are identified, they
will be put on the first list. I'll pick one or two at a time for
discussion on Common Lisp, and will call for a vote of the technical
committee when things seem to have converged to a specific proposal or
choice between a couple of options. Advice from any of you is welcome
-- what issue to bring up next, etc. -- but it would be helpful if you'd
try not to start new discussions while old ones are still raging. I'll
probably start with something current, like what goes into the LISP
package, and then try to whip through the proposals Steele made in
Boston.
Concurrently, I'll get to work on a document. This will be kept on
view, and again kibitzing is invited. Of course, it is more helpful if
you propose specific changes (or want to rewrite whole sections) than if
you just say that you don't like something.
There are some things that I'd like help on:
I believe that Guy volunteered a while ago to look over the
floating-point stuff (perhaps with help from Hilfinger and others) and
to make a specific proposal on what changes we should make. I have no
competence in this area.
I'd like a couple of volunteers to take a close look at KMP's error
proposal (and the code for it, when it becomes available) to see if this
is really what we want to live with for the next five years or so. I
believe that Moon has already beaten on this extensively, but we need
some other perspectives. I like what I see, in general, but I haven't
had time to think hard about this. Once there is a proposal that
several of us like, we can put it forward for final discussion, voting,
and possible adoption.
Does anyone want to take a crack at the whole knotted mess surrounding
"top-level forms", Eval-When or some replacement for it, and what the
compiler does with various forms at compile, load, and eval time? This
might leak over into consideration of facilities for separate
compilation, package hackery, etc. The point is to sepcify those things
that must be specified in order to make it easy to write portable code
for large, complex systems. If nobody else wants this, I'll get to it
eventually, but help in thinking it all through would be very welcome.
It would be useful if Bobrow and Moon could discuss whether there is
enough common ground between new flavors and Commonloops to support a
usable standard object-oriented facility, with some of the more
controversial things (e.g. the declarative method-combination stuff in
flavors) as add-ons. If there's common ground there, and if we can
satisfy some of the concerns Alan Snyder has raised, maybe we've got
critical mass. It would be very nice if we could have the rough
outlines of a system we could all live with before the Lisp Conference.
If it can't be done, it can't be done, but we should try. I've got a
feeling that if we don't act soon, each group is going to get locked
into its own way of handling this. CommonLoops looks like the winner
for about half the communtiy, but there will be large factions using the
other systems.
I'm happy to have people not on the technical committee working on these
proposals -- some very good people are not on the committee just because
we didn't want to over-represent certain companies -- but I would like
someone on the technical committee to coordinate each of these things.
-- Scott
∂17-Jun-86 2140 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM Technical progress
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 17 Jun 86 21:40:21 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 24116; Wed 18-Jun-86 00:39:20 EDT
Date: Wed, 18 Jun 86 00:36 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Technical progress
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>
cc: cl-steering@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12215664748.BABYL@C.CS.CMU.EDU>
Message-ID: <860618003612.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
A good place to start, in looking for issues to be resolved, would
be the messages several people (Kent Pitman is the only name I
remember, I think because he's the only one I know personally)
sent within the past couple of months describing their experience
porting actual, live programs between several actual, live Common
Lisp implementations.
As for agreeing on a standard object-oriented programming system
before the Lisp conference (i.e. in six weeks), I hate to pick on
you when you're volunteering to do so much work, but I have to say
that you're dreaming. Bobrow and I get along pretty well, I think,
but nobody ever made a standard in six weeks. Anything we said in
that time would be vacuous. I don't even understand everything that
Common Loops is trying to do yet. (Is there a better document than
the one from last year? I've been hoping, but I realize it's
difficult to write such things.)
∂18-Jun-86 0539 MATHIS@USC-ISIF.ARPA Re: Standards
Received: from USC-ISIF.ARPA by SU-AI.ARPA with TCP; 18 Jun 86 05:39:26 PDT
Date: 18 Jun 1986 05:38-PDT
Sender: MATHIS@USC-ISIF.ARPA
Subject: Re: Standards
From: MATHIS@USC-ISIF.ARPA
To: Fahlman@C.CS.CMU.EDU
Cc: cl-steering@SU-AI.ARPA
Message-ID: <[USC-ISIF.ARPA]18-Jun-86 05:38:31.MATHIS>
In-Reply-To: <FAHLMAN.12214816283.BABYL@C.CS.CMU.EDU>
Scott,
The Uk people were incorrect in their criticism of US actions.
We had to send the proposals through US bodies in the way that we
did because of US internal procedures (they are very different in
each country). Secondly it is not against ISO rules for coutries
to have different standards -- the most notable example is Pascal
and the British make us remember it every chance they get.
The traditional way for programming language standards to be
developed is by the US and then adopted by ISO (eg, Fortran,
Cobol, Ada -- the three biggest). Here we are trying for an ISO
standard dierectly, but must also be prepared to do an ANSI
standard by itself if necessary.
I pointed all this out at the meeting, sorry I forgot to point it
out in my notes.
-- Bob
∂18-Jun-86 0704 DLW@ELEPHANT-BUTTE.SCRC.Symbolics.COM Technical progress
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 18 Jun 86 07:04:27 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 24278; Wed 18-Jun-86 10:03:27 EDT
Date: Wed, 18 Jun 86 10:06 EDT
From: Daniel L. Weinreb <DLW@QUABBIN.SCRC.Symbolics.COM>
Subject: Technical progress
To: Fahlman@CMU-CS-C.ARPA, cl-steering@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12215664748.BABYL@C.CS.CMU.EDU>
Message-ID: <860618100611.5.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: Tue, 17 Jun 1986 21:30 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
I'll probably start with something current, like what goes into the LISP
package, and then try to whip through the proposals Steele made in
Boston.
It might be best to start with things that seem to least controversial,
for morale purposes. If a bunch of decisions go quickly and smoothly,
we'll all feel better about the process. The recent mail about package
organization seems interminable, possibly because the arguments are
based on rather subjective considerations sometimes.
I'd like a couple of volunteers...
Is CL-Steering the right place to send this request? Perhaps you should
send this to the technical committee.
It would be useful if Bobrow and Moon could discuss whether there is
enough common ground between new flavors and Commonloops...
As far as I have heard, there is still no definition of Commonloops.
I've been interested in it, and would like to discuss and evaluate it,
but without any written definition, it's rather hard. Something whose
form was not unlike CLtL would be fine with me; I don't need a highly
formal mathematical definition of anything. The paper that has been
widely circulated is far from a definition; for example, what are the
generic operations on metaclasses? But so far this is what's been
holding my ability to understand, and say anything intelligent about,
Commonloops. (Note: yes, I have a copy of the source code of the
portable implementation, but it is extremely difficult or impossible to
induce a definition from a specific implementation. Yes, I have tried.)
∂18-Jun-86 0810 FAHLMAN@C.CS.CMU.EDU Technical progress
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 18 Jun 86 08:09:50 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 18 Jun 86 11:09:17-EDT
Date: Wed, 18 Jun 1986 11:09 EDT
Message-ID: <FAHLMAN.12215813759.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "Daniel L. Weinreb" <DLW@SCRC-QUABBIN.ARPA>
Cc: cl-steering@SU-AI.ARPA
Subject: Technical progress
In-reply-to: Msg of 18 Jun 1986 10:06-EDT from Daniel L. Weinreb <DLW at QUABBIN.SCRC.Symbolics.COM>
It might be best to start with things that seem to least controversial,
for morale purposes.
Good point.
I'd like a couple of volunteers...
Is CL-Steering the right place to send this request? Perhaps you should
send this to the technical committee.
Well, I didn't expect any of the steering-only people to volunteer, but
they need to be aware of what we're planning to do, in broad terms.
Once we get down to narrow technical chatter I'll switch to the other
list.
I agree with you and Moon that there's no possible way of producing an
object spec by the time of the Lisp Conference. What I was hoping
(dreaming, perhaps) was that some internal discussion might reveal to us
whether there is a good chance that we might be able to agree on an
object system by the time the rest of this stuff is done, and some ideas
about what that spec might contain. (My internal goal, and it's only a
goal and not a promise, is that we can have a proposed spec for Common
Lisp ready to go by the end of this calendar year.) Or should we just
tell the world that there's no way this will get done and the
standardization of an object-oriented system will have to be done later,
if at all.
It looks to me like CommonLoops and New Flavors overlap substantially.
I realize that many people are suspicious of the multiple-arg dispatch,
but that's looking better and better to me the more I think about it.
(Think hard about doing arithmetic and Macsyma-style stuff with and
without this, and it will start looking very good -- at least, that's
what keeps pulling me back to this.) The declarative combination stuff
from Flavors is controversial, but also probably separable. The Xerox
people have talked with Snyder about his encapsulation concerns, and I
believe they agree there are reasonable ways of accommodating these
things for users who want that kind of protection instead of the
conveneience of default inheritance. (Yes, I know that all of this is
an over-simplification.)
The rest of you may or may not see the world this way, but if you do, I
think that we should be able to say with some confidence that a proposal
could be developed in the course of several months, and we could say
roughly what level of stuff would be within the standard and what would
be add-on. Not to decide is to decide. Six weeks isn't a very long
time, but it seemed worthwhile to take a poke at this, at least to
determine whether there has been any convergence since January. Maybe
it's just too early to start, however, and we'll have to look at this
again in September, after the CommonLoops people and others have
polished their act a bit.
-- Scott
∂18-Jun-86 0815 FAHLMAN@C.CS.CMU.EDU Standards
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 18 Jun 86 08:15:07 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 18 Jun 86 11:14:53-EDT
Date: Wed, 18 Jun 1986 11:14 EDT
Message-ID: <FAHLMAN.12215814792.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: MATHIS@USC-ISIF.ARPA
Cc: cl-steering@SU-AI.ARPA
Subject: Standards
In-reply-to: Msg of 18 Jun 1986 08:38-EDT from MATHIS at USC-ISIF.ARPA
That's good news. So if we do a good job technically, I don't see any
way we can be blocked at the ANSI level. If ISO should adopt a
different Lisp standard, we can just say that their Lisp and Common Lisp
are different languages with different goals.
-- Scott
∂18-Jun-86 0916 DLW@ELEPHANT-BUTTE.SCRC.Symbolics.COM Technical progress
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 18 Jun 86 09:16:12 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 24440; Wed 18-Jun-86 12:02:57 EDT
Date: Wed, 18 Jun 86 12:05 EDT
From: Daniel L. Weinreb <DLW@QUABBIN.SCRC.Symbolics.COM>
Subject: Technical progress
To: Fahlman@CMU-CS-C.ARPA
cc: cl-steering@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12215813759.BABYL@C.CS.CMU.EDU>
Message-ID: <860618120545.1.DLW@CHICOPEE.SCRC.Symbolics.COM>
I agree that there is substantial overlap between New Flavors and
CommonLoops, and I also have been expecting that we'd be in discussions
with the CommonLoops designers to try to come up with some kind of
standards proposal. However, I've felt unable to proceed because I
really don't know what CommonLoops is; I only know certain facts and
claims about it, from the paper that's been distributed. Perhaps if you
could help to encourage the CommonLoops designers to come up with a real
description of what CommonLoops is, just what it can do, and just how
you use it.
(Note that I am speaking for myself; I am not certain of all of Moon's
opinions, so please don't assume that he agrees with me on everything.
However, I think that he probably would agree with much of the above.)
∂18-Jun-86 1002 RPG Volunteer
To: cl-steering@SU-AI.ARPA
I will do EVAL-WHEN.
-rpg-
∂18-Jun-86 1254 Bobrow.pa@Xerox.COM Re: Technical progress
Received: from XEROX.COM by SU-AI.ARPA with TCP; 18 Jun 86 12:54:17 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 18 JUN 86 12:53:54 PDT
Date: 18 Jun 86 12:52 PDT
Sender: Bobrow.pa@Xerox.COM
Subject: Re: Technical progress
In-reply-to: Daniel L. Weinreb <DLW@QUABBIN.SCRC.Symbolics.COM>'s
message of Wed, 18 Jun 86 10:06 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM,DLW@QUABBIN.SCRC.Symbolics.COM
cc: Fahlman@C.CS.CMU.EDU, cl-steering@SU-AI.ARPA
From: Bobrow.pa@Xerox.COM (Danny Bobrow)
Message-ID: <860618-125354-1783@Xerox>
I agree with Moon that defining a standard in 6 weeks is impossible.
Even if we agreed on everything writing the document would take longer.
I also sympathise with DLW and Moon's desire for a more formal
specification of CommonLoops, particularly the meta-object protocol
(what DLW calls "the generic operations on meta-classes"). We have
begun working on such a document, we will try to make a draft available
in a couple of weeks. Given our first draft of the spec distributed
soon, net traffic can be used to understand areas of potential problems.
If it is desirable we can plan to get together before or concurrent with
the Lisp conference.
With agreement on some of the spec, we might be able to make some
statement about the object-standard at the Lisp conference. If we could
say that we have agreed on the default mechanisms for defining methods
and classes, and that we are working on a meta-object protocol, that
would make it clear that there is enough convergence to allow people to
write programs. They could use either PCL or New Flavors as the
implementation for code that would continue to work.
The major issue is of course meta-objects. I think most of the other
issues are pretty simple. For example:
1) Method Combination: Gregor is currently implementing the user defined
declarative method combination interface specified by Moon. This fits
quite nicely into CommonLoops, although the implementation technique is
quite different when you have meta-objects.
2) Multimethods: are a win for us, and don't interfere with classical
methods.
3) Syntax: We are not wedded to any of our defining form syntax. We
have avoided syntactic conflicts with (New) Flavors to make it easier to
port either kind of program in the face of standardization.
Some uses we have made of metaobject:
Metaclasses have allowed us to define classes for the built-in types,
and hence to define methods specialized to those types. (This could
clearly have been allowed in New Flavors without metaclasses, but it
does make it natural).
We have explored combining logic calls with objects by implementing a
logic-discriminator (one that does unification on its arguments, and
backtracks on "failure").
We have hand waved with Gary Drescher about how one could get some of
his favorite features. Perhaps a meeting with LMI will make that
clearer.
We are quite sympathetic with people who want a standard now. It is
good to know what the future will hold. Let's try to hurry it along as
fast as our little parentheses will travel.
-- danny
∂20-Jun-86 0154 FAHLMAN@C.CS.CMU.EDU Copyrights
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 19 Jun 86 19:07:54 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 19 Jun 86 22:07:51-EDT
Date: Thu, 19 Jun 1986 22:07 EDT
Message-ID: <FAHLMAN.12216195800.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-steering@SU-AI.ARPA
Cc: fahlman@C.CS.CMU.EDU
Subject: Copyrights
I propose to put the following notice on each of the files that are part
of the new language definition:
---------------------------------------------------------------------------
Copyright (C) 1986 by Scott E. Fahlman
This file is part of a new language definition document for Common Lisp,
which is being developed as a possible basis for official
standardization of Common Lisp. Until this specification has been
completed and approved by a recognized standards organization, it should
be viewed as an informal proposal with no official status. Implementors
who choose to follow this language definition do so at their own risk
and discretion.
Permission is hereby granted to individuals and organizations
participating in the Common Lisp design process to make as many copies
of this file as may be necessary for their own use in this design
activity. This notice must be included in any such copies.
---------------------------------------------------------------------------
Does anyone see any problems here, aside from the aforementioned
nervousness about having a single individual hold the copyright (which
we will deal with as soon as we understand how to do so)? This
statement has not been lawyerized.
-- Scott
∂20-Jun-86 0154 gls@Think.COM The Eulisp paper
Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 19 Jun 86 19:24:59 PDT
Received: from thorlac by Godot.Think.COM via CHAOS; Thu, 19 Jun 86 22:24:53 edt
Date: Thu, 19 Jun 86 22:26 EDT
From: Guy Steele <gls@Think.COM>
Subject: The Eulisp paper
To: cl-steering@SU-AI.ARPA
Cc: gls@AQUINAS
Message-Id: <860619222609.4.GLS@THORLAC.THINK.COM>
I have read the Eulisp position paper carefully, and my initial reaction
was similar to Moon's, namely to come down a bit on the side of optimism
and generosity. If I take the paper at face value, ignoring all outside
information about possible politics, grudges, and other motivations,
then I derive the following conclusions:
(1) The proposed program of activity is a perfectly reasonable pursuit,
academically and technically. There's nothing wrong with a formal
definition if someone wants to do the work to pull it off. The notion
of a layered definition is reasonable.
(2) The authors have not carefully read the Common Lisp specification,
for the paper contains a number of egregious errors concerning both the
goals and technical content of Common Lisp. More generally, the authors
put blame on the developers of Common Lisp for ignoring dialects other
than Maclisp, but are themselves ignorant of certain aspects of Lisp
history and fail to give due credit in a number of instances.
(3) The authors confuse the activity of design with the activity of
standardization, and fail to realize that a large committee is much less
effective than a small one. [This is something we failed to realize at
first, too, and the design Common Lisp converged only when the committee
was effectively cut down to a managable size, namely five. My
experience on the ANSI C committee was that no more than a dozen
representatives were really actively involved most of the time; the rest
were just there to listen and vote.]
(4) The authors grossly underestimate the amount of effort involved in
the design and the standardization of a language of the size under
consideration. Common Lisp has been in the works for five years. It
will be at least five years before any Eulisp proposal is in any kind of
shape worth voting on at the ISO level. The documents produced so far
for Eulisp are rather poor, and they tackle the easiest parts (CAR, CDR,
etc.). They are poor not necessarily because of the quality of the
authorship, but merely because polishing a document takes lots of time
and energy, and enough time has not yet passed.
I think the main problem is that the Eulisp folks think that if they
block Common Lisp now, they can take the world by storm within the next
year. This is balderdash. If the authors of the Eulisp paper had a
realistic estimate of how long the Eulisp effort would take, they would
not fear Common Lisp. By 1991 it will be time for a gross revision of
any new Lisp standard anyway. Similarly, Common lisp proponents need
not fear Eulisp except to the extent that it might block timely adoption
of Common Lisp. Common Lisp is almost ready now, and Eulisp is a long
way away.
Do you all think that if all parties could be convinced of this then
they could cooperate on both things within their appropriate time frames?
--Guy
∂20-Jun-86 0219 FAHLMAN@C.CS.CMU.EDU Where it all lives
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 19 Jun 86 20:13:28 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 19 Jun 86 23:13:31-EDT
Date: Thu, 19 Jun 1986 23:13 EDT
Message-ID: <FAHLMAN.12216207760.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-steering@SU-AI.ARPA
Subject: Where it all lives
I have set up the appropriate book-keeping files on C.CS.CMU.EDU (a
Dec-20) in directory PRVA:<SLISP.STANDARD>. Everything should be set up
to allow anonymous FTP. Sorry about the ugly directory name. It
happens to be a place where I could get a large amount of file space for
this work without a lot of hassle -- something of an accomplishment at
CMU these days. The files are just shells right now; I'll start filling
them soon.
Once things have taken shape a bit more, I will announce where these
things live to the Common-Lisp list.
People on the ARPAnet should have no problem in accessing these things
directly; others may need tape or hardcopy from time to time. I don't
want to get CMU (and myself) involved in distributing this stuff the
hard way. I'm hoping that ISI can do this, once their DARPA contract
for Common Lisp support is set up, or that some other organization will
be willing to do this.
-- Scott
∂20-Jun-86 0744 FAHLMAN@C.CS.CMU.EDU The Eulisp paper
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 20 Jun 86 07:44:24 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 20 Jun 86 10:44:27-EDT
Date: Fri, 20 Jun 1986 10:44 EDT
Message-ID: <FAHLMAN.12216333537.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Guy Steele <gls@ZARATHUSTRA.THINK.COM>
Cc: cl-steering@SU-AI.ARPA
Subject: The Eulisp paper
In-reply-to: Msg of 19 Jun 1986 22:26-EDT from Guy Steele <gls at Think.COM>
I think that Guy's note captures the essence of the situation very well.
I have felt for some time that the EuLisp group has a better than even
chance of disintegrating when they get to the hard stuff, and when they
realize that there are choices to be made between elegance and
usability. Our group had much more incentive to stay together,
excellent communications, more similarity of goals than they have
exhibited so far, more realistic expectations (since most of the inner
circle had substantial implementation experience for industrial-strength
Lisp systems), and still we just barely hung together through some of
the hardest parts. And it did take five years.
If we can get the Europeans to drop their opposition to Common Lisp
standardization, we achieve our immediate goal, and their long-term
chances of success look much better: they won't have a deadline, lots of
people in the U.S. would like to contribute ideas for the next great
Lisp (if such participation is welcome), and they will be able to go
forward without a lot of concern for compatibility with the past --
there's always Common Lisp if you need to run old code. The only
disadvantage to them is that their Lisp will have to make it mostly on
its merits, and not on political clout. But they don't really have
political clout anyway: if they were to whip up a level-0 spec by year's
end and ram it through ISO, do they really think that people will
abandon Common Lisp and use their thing?
Maybe we can persuade them to see it this way. It may be that the
majority of the Europeans are about ready to see things as Guy describes
them, but I would be surprised if Stoyan, Fitch, and Padgett were
willing to back down in public. We must keep our eyes open for some
face-saving way of producing the desired result.
-- Scott
∂20-Jun-86 1439 OHLANDER@USC-ISIB.ARPA Re: Copyrights
Received: from USC-ISIB.ARPA by SU-AI.ARPA with TCP; 20 Jun 86 14:39:24 PDT
Date: 20 Jun 1986 14:38-PDT
Sender: OHLANDER@USC-ISIB.ARPA
Subject: Re: Copyrights
From: OHLANDER@USC-ISIB.ARPA
To: Fahlman@C.CS.CMU.EDU
Cc: cl-steering@SU-AI.ARPA
Message-ID: <[USC-ISIB.ARPA]20-Jun-86 14:38:56.OHLANDER>
In-Reply-To: <FAHLMAN.12216195800.BABYL@C.CS.CMU.EDU>
Scott,
I see no problem with the exception that you pointed out.
I think it should probably be run by a lawyer.
Ron
∂22-Jun-86 1844 DLW@ELEPHANT-BUTTE.SCRC.Symbolics.COM The Eulisp paper
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 22 Jun 86 18:44:09 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 27356; Sun 22-Jun-86 13:45:20 EDT
Date: Sun, 22 Jun 86 13:48 EDT
From: Daniel L. Weinreb <DLW@QUABBIN.SCRC.Symbolics.COM>
Subject: The Eulisp paper
To: Fahlman@CMU-CS-C.ARPA
cc: cl-steering@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12216333537.BABYL@C.CS.CMU.EDU>
Message-ID: <860622134836.5.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: Fri, 20 Jun 1986 10:44 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
I have felt for some time that the EuLisp group has a better than even
chance of disintegrating when they get to the hard stuff,
I agree. It also seems to me that the more time they spend on politics,
banding together to fight the Americans, the less chance there is of
their disintegrating. Therefore, perhaps our best tactic would be to
try to defuse, defer, or avoid politics and conflict, and encourage them
to work on the technical aspects of their proposal.
On another topic, I just received mail from Japan, with a return address
of JEIDA's office, containing a blue paperback volume, written in
Japanese, designated 61-A-236, entitled "Common Lisp" followed by
Japanese. There's a sticker on it saying "on behalf of Prof. M. Ida".
It contains a great deal of discussion about CommonLoops, Flavors,
CommonObjects (which it refers to as "Snyder"), and ObjectLisp, complete
with what appear to be lots of excerpts from electronic mail by many
well-known people. It looks like it's a comparison. The book also has
a long section with many bar charts, a copy of Ida's subset proposal (in
English), and various other stuff. I presume many or all of you will
get copies. I wonder what it all says.
∂22-Jun-86 1920 FAHLMAN@C.CS.CMU.EDU The Eulisp paper
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 22 Jun 86 19:18:54 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 22 Jun 86 22:18:09-EDT
Date: Sun, 22 Jun 1986 22:18 EDT
Message-ID: <FAHLMAN.12216984117.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "Daniel L. Weinreb" <DLW@SCRC-QUABBIN.ARPA>
Cc: cl-steering@SU-AI.ARPA
Subject: The Eulisp paper
In-reply-to: Msg of 22 Jun 1986 13:48-EDT from Daniel L. Weinreb <DLW at QUABBIN.SCRC.Symbolics.COM>
I wonder what it all says...
I got one of those books too. It's some sort of script for a new TV
show. Kind of like Dallas, except that instead of an oil company, the
main characters are working for rival companies defining programming
languages. Lots of back-stabbing, mind-altering drugs (mostly Coke),
high-speed CPU chases and crashes, and steamy sex with the Lisp
groupies. Some sort of subplot involving a bunch of Europeans trying to
kidnap the fearless band of hackers and force them to alter the
semantics of NIL. The censors will snip that bit out for U.S.
consumption -- you can't mess around with NIl on American TV. A guest
appearance by Godzilla as the head of JEIDA.
Of course, I don't read Japanese very well, so this might not be 100%
accurate, but as I understand it the little splatty marks mean whatever
they look like, and it all seems pretty clear to me.
-- Scott
∂26-Jun-86 0810 gls@Think.COM Copyrights
Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 26 Jun 86 08:09:27 PDT
Received: from boethius by Godot.Think.COM via CHAOS; Thu, 26 Jun 86 11:09:14 edt
Date: Thu, 26 Jun 86 11:10 EDT
From: Guy Steele <gls@Think.COM>
Subject: Copyrights
To: Fahlman@C.CS.CMU.EDU, cl-steering@SU-AI.ARPA
Cc: gls@AQUINAS
In-Reply-To: <FAHLMAN.12216195800.BABYL@C.CS.CMU.EDU>
Message-Id: <860626111018.5.GLS@BOETHIUS.THINK.COM>
Scott,
In the copyright notice, you might want to add a phrase such as "but
not for profit" in the permission-granting sentence, the point being
that it's not reasonable for a company to print up N copies of these
files and sell them at a profit (selling at cost as a service is
presumably okay). Otherwise it looks okay to me (a non-lawyer).
--Guy
∂26-Jun-86 1009 FAHLMAN@C.CS.CMU.EDU Copyrights
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 26 Jun 86 10:09:12 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 26 Jun 86 13:08:54-EDT
Date: Thu, 26 Jun 1986 13:08 EDT
Message-ID: <FAHLMAN.12217932696.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Guy Steele <gls@ZARATHUSTRA.THINK.COM>
Cc: cl-steering@SU-AI.ARPA
Subject: Copyrights
In-reply-to: Msg of 26 Jun 1986 11:10-EDT from Guy Steele <gls at Think.COM>
Thanks, I'll add that. It seems redundant, but can't hurt.
What are your thoughts about producing a second edition of CLtL sometime
after the formal spec is out? I'm assuming that this would be
explicitly non-definitive and would point to the ANSI spec, but would be
more accessible to the casual user, as the current book is. This would
be between you and Digital Press, but I'd like to encourage you to do
this. Pat Winston commented to me that the accessible style of your
book has had a lot to do with the success of the language, and it would
be a shame to leave it behind in favor of something dry and definitive.
I'm inclined to agree.
-- Scott
∂26-Jun-86 1011 FAHLMAN@C.CS.CMU.EDU Copyrights
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 26 Jun 86 10:11:28 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 26 Jun 86 13:11:24-EDT
Date: Thu, 26 Jun 1986 13:11 EDT
Message-ID: <FAHLMAN.12217933154.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Guy Steele <gls@ZARATHUSTRA.THINK.COM>
Cc: cl-steering@SU-AI.ARPA
Subject: Copyrights
In-reply-to: Msg of 26 Jun 1986 11:10-EDT from Guy Steele <gls at Think.COM>
Here's revised text for the "permission" part:
Permission is hereby granted to individuals and organizations
participating in the Common Lisp design process to make as many copies
of this file as may be necessary for their own use in this design
activity, provided that such copies are not sold for profit. This
notice must be included in any such copies.
∂26-Jun-86 1055 MATHIS@USC-ISIF.ARPA Copyright notice
Received: from USC-ISIF.ARPA by SU-AI.ARPA with TCP; 26 Jun 86 10:55:08 PDT
Date: 26 Jun 1986 10:55-PDT
Sender: MATHIS@USC-ISIF.ARPA
Subject: Copyright notice
From: MATHIS@USC-ISIF.ARPA
To: cl-steering@SU-AI.ARPA
Message-ID: <[USC-ISIF.ARPA]26-Jun-86 10:55:03.MATHIS>
In the Ada design files there was also a phrase saying these
drafts should not be referenced. Scott's words already imply the
working nature of the files, but maybe that ought to be
emphasized.
In the X3J13 context we will have to freeze versions as portions
of the draft under consideration. These versions of the files
should probably have an additional notation to that effect
Since I view these as working documents they will probably have
frequent changes. That means they should incorporate a date in
the header. I don't think we want to go into the "change bar"
business between versions though.
You'll notice we all seem to be comfortable with Scott holding
the copyright and most of the comments are about other aspects of
the header.
As to reprints, X3J13 already has about a dozen interested people
who used regular mail to contact me. When we get to the stage of
discussing and voting on drafts, we will have to make some
hardcopies. We don't need to say it in the header, but whatever
distribution X3J13 makes will probably be the most convenient for
anyone until we reach a full draft for X3 and ANSI consideration.
-- Bob
∂27-Jun-86 1130 gls@Think.COM Copyrights
Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 27 Jun 86 11:30:09 PDT
Received: from boethius by Godot.Think.COM via CHAOS; Fri, 27 Jun 86 14:29:35 edt
Date: Fri, 27 Jun 86 14:30 EDT
From: Guy Steele <gls@Think.COM>
Subject: Copyrights
To: Fahlman@C.CS.CMU.EDU
Cc: cl-steering@SU-AI.ARPA, gls@AQUINAS
In-Reply-To: <FAHLMAN.12217932696.BABYL@C.CS.CMU.EDU>
Message-Id: <860627143041.5.GLS@BOETHIUS.THINK.COM>
Date: Thu, 26 Jun 1986 13:08 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Thanks, I'll add that. It seems redundant, but can't hurt.
What are your thoughts about producing a second edition of CLtL sometime
after the formal spec is out? I'm assuming that this would be
explicitly non-definitive and would point to the ANSI spec, but would be
more accessible to the casual user, as the current book is. This would
be between you and Digital Press, but I'd like to encourage you to do
this. Pat Winston commented to me that the accessible style of your
book has had a lot to do with the success of the language, and it would
be a shame to leave it behind in favor of something dry and definitive.
I'm inclined to agree.
-- Scott
Frankly, I have always cherished the hope that a specification could be
definitive without being dry. Now that I've seen how easily CLtL has been
shot full of holes, maybe I should know better. I had thought to invest
most of my effort into helping with the official spec, whatever the starting
point. If you think that on balance it would be useful to have the ANSI
spec and also a second edition of CLtL, then by all means I will see the
latter through.
--Guy
∂27-Jun-86 1204 FAHLMAN@C.CS.CMU.EDU Copyrights
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 27 Jun 86 12:04:28 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 27 Jun 86 15:04:26-EDT
Date: Fri, 27 Jun 1986 15:04 EDT
Message-ID: <FAHLMAN.12218215878.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Guy Steele <gls@ZARATHUSTRA.THINK.COM>
Cc: cl-steering@SU-AI.ARPA
Subject: Copyrights
In-reply-to: Msg of 27 Jun 1986 14:30-EDT from Guy Steele <gls at Think.COM>
Frankly, I have always cherished the hope that a specification could be
definitive without being dry.
Well, that's possible, but given that it seems necessary to start the
spec from scratch, I think we'd better concentrate on doing just one job
as well as possible, and not adding a lot of friendliness features. So
"CLtL II" will help to fill a real need. Also, you would have the
option of taking out some of the implementors-only stuff if you care to
-- the careful language about just what is required and to what degree.
Once the spec is in reasonably good shape, it shouldn't be hard for you
to fix up the book; I mention it now because you may want to track the
spec changes rather than doing this in a burst at the end.
-- Scott
∂27-Jun-86 1641 DLW@ELEPHANT-BUTTE.SCRC.Symbolics.COM Copyrights
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 27 Jun 86 16:41:41 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 31607; Fri 27-Jun-86 17:01:12 EDT
Date: Fri, 27 Jun 86 17:05 EDT
From: Daniel L. Weinreb <DLW@QUABBIN.SCRC.Symbolics.COM>
Subject: Copyrights
To: Fahlman@CMU-CS-C.ARPA
cc: cl-steering@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12218215878.BABYL@C.CS.CMU.EDU>
Message-ID: <860627170533.2.DLW@CHICOPEE.SCRC.Symbolics.COM>
Unfortunately, no matter how careful all of us are, it seems inevitable
that CLtL II will contain phrasing that will seem to be, in some way,
contradictory to the phrasing in the official spec, from time to time.
Of course there is no question which one of these takes precedence.
Nevertheless, CLtL reads pretty much like a reference manual, and anyone
reading it would be likely to think that whatever it says can be assumed
to be official Common Lisp. You, as a matter of fact, are probably the
person who has said the most about the evils of having more than one thing
that looks like a Common Lisp reference manual!
On the other hand, a revised CLtL based on the language revisions is
certainly a better thing to have floating around than the original CLtL.
And a more readable version of the spec is valuable in many ways as
well. So I'm not arguing against the revision of the book; just
pointing out the dangers. Maybe we can think of steps to take to
minimize the potential problems.
∂27-Jun-86 1720 FAHLMAN@C.CS.CMU.EDU Copyrights
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 27 Jun 86 17:20:05 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 27 Jun 86 20:19:37-EDT
Date: Fri, 27 Jun 1986 20:19 EDT
Message-ID: <FAHLMAN.12218273255.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "Daniel L. Weinreb" <DLW@SCRC-QUABBIN.ARPA>
Cc: cl-steering@SU-AI.ARPA
Subject: Copyrights
In-reply-to: Msg of 27 Jun 1986 17:05-EDT from Daniel L. Weinreb <DLW at QUABBIN.SCRC.Symbolics.COM>
You, as a matter of fact, are probably the
person who has said the most about the evils of having more than one thing
that looks like a Common Lisp reference manual!
Well, not exactly. Everyone now treats CLtL as the definitive
definition of Common Lisp, and I have pointed out the confusion that
would be caused if slightly deviant editions of that manual appeared,
all claiming equal status. People would naturally assume that THEIR
copy is definitive. However, if CLtL II were to state clearly and
prominently that the technical committee's document is definitive in the
case of any discrepancies then such confusion couldn't arise except in
the minds of people who don't read the warning label.
Of course, if there are glaring technical errors in CLtL II, it could
cause people a lot of trouble because they would only look in the
ANSI/ISO spec after a problem has screwed them, but with a bit of care
it should be possible to catch any errors that would burn people
frequently.
-- Scott
∂27-Jun-86 1752 DLW@ELEPHANT-BUTTE.SCRC.Symbolics.COM Copyrights
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 27 Jun 86 17:52:40 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 31792; Fri 27-Jun-86 20:48:42 EDT
Date: Fri, 27 Jun 86 20:52 EDT
From: Daniel L. Weinreb <DLW@QUABBIN.SCRC.Symbolics.COM>
Subject: Copyrights
To: Fahlman@CMU-CS-C.ARPA
cc: cl-steering@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12218273255.BABYL@C.CS.CMU.EDU>
Message-ID: <860627205253.7.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: Fri, 27 Jun 1986 20:19 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Of course, if there are glaring technical errors in CLtL II, it could
cause people a lot of trouble because they would only look in the
ANSI/ISO spec after a problem has screwed them, but with a bit of care
it should be possible to catch any errors that would burn people
frequently.
Glaring technical errors aren't what I'm worried about. My worry stems
from my observation that the wording in CLtL sometimes seems to carry
certain meanings, but one is not always quite sure. For example, after
several of us here studied all the text about pervasiveness of special
declarations that we could find, we found that we had to piece together
little assertions from here and there in order to answer certain
specific quesetions about how the pervasiveness is defined to work.
After a while, I was not certain that the intent of the design was the
same as what the text seemed to imply. It's this kind of thing that
worried me. I'm afraid someone will read a description of something,
not realize anything is wrong, and walk away with a misimpression, but
feel that since the book is CLtL, what it describes must correspond to
Common Lisp. In other words, I'm worried about passages that look
error-free when you or I read them, but that turn out to have subtle
ambiguities, or even errors, when these passages are consulted to answer
specific questions.
I'm sorry if this is vague; I'm having a hard time expressing it. Since
I have no real constructive suggestions to make, you might as well
forget about my comments. I do want to emphasize that I am not trying
to criticize Steele's writing, which I think is excellent; I view this
problem as more or less inevitable given the kind of book CLtL is trying
to be.
Actually, here's one constructive suggestion: at various point, CLtL II
should say things like "See the ANSI/ISO spec, section 4.2.3.1, for a
complete description" or "... for the official formal description" or
something like that. Then CLtL II could serve as a useful index to the
official spec, and you'd be able to avoid the presumably harder-to-read
spec most of the time, but switch to it readily when there's some subtle
point to be resolved.
∂30-Jun-86 1111 gls@Think.COM Copyrights
Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 30 Jun 86 11:10:39 PDT
Received: from katherine by Godot.Think.COM via CHAOS; Mon, 30 Jun 86 14:09:57 edt
Date: Mon, 30 Jun 86 14:11 EDT
From: Guy Steele <gls@Think.COM>
Subject: Copyrights
To: DLW@QUABBIN.SCRC.Symbolics.COM
Cc: cl-steering@SU-AI.ARPA
In-Reply-To: <860627205253.7.DLW@CHICOPEE.SCRC.Symbolics.COM>
Message-Id: <860630141101.3.GLS@KATHERINE.THINK.COM>
I too am concerned about the subtle discrepancies that can occur. The
number of discrepancies that can occur just within a single document
(CLtL) that is supposedly definitive has been staggering. Despite all
kind words to the contrary, many of these problems are indeed my fault.
Others I am willing to chalk up to "Gee, it's a big difficult mess."
Dan's suggestion that a CLtL II should contain pointers into the formal
spec is a very good point, and might alleviate this problem to some extent.
In other words, don't warn the reader only once that the formal spec takes
precedence, but constantly remind him of the fact in relevant places.
--Guy
∂02-Jul-86 1032 berman@vaxa.isi.edu Support Proposal
Received: from VAXA.ISI.EDU by SU-AI.ARPA with TCP; 2 Jul 86 10:32:10 PDT
Received: by vaxa.isi.edu (4.12/4.7)
id AA04138; Wed, 2 Jul 86 10:31:21 pdt
From: berman@vaxa.isi.edu (Richard Berman)
Message-Id: <8607021731.AA04138@vaxa.isi.edu>
Date: 2 Jul 1986 1031-PDT (Wednesday)
To: CL-Steering@su-ai.arpa
Cc:
Subject: Support Proposal
------- Forwarded Message
Sender: FAHLMAN@C.CS.CMU.EDU
To: berman@λvaxa.isi.eduλ (Richard Berman)
Subject: Validation status
In-Reply-To: Msg of 1 Jul 1986 17:14-EDT from berman at vaxa.isi.edu (Richard Berman)
Richard,
Thanks for the progress report. I don't see Lucid in there anywhere.
have they reneged on their promise?
I'd like to have a look at the support proposl you're sending in. In
fact, all of the technical and steering committee members should
probably see this. They can all be reached by mail to
CL-Steering@su-ai. Ohlander is on the steering committee if there are
questions.
Glad to see you're rolling.
-- Scott
------- End of Forwarded Message
OK -- Here it is...
COMMON LISP SUPPORT
1. Background
The effort by the Common Lisp community to define and propagate a Common Lisp
Standard is well under way. At the just concluded Common Lisp Meeting,
agreement was reached to pursue such standardization under ISO. Bob Mathis,
who helped guide the ADA standardization and validation efforts from his post
as head of AJPO, has been chosen as the convener of an expanded technical
committee to address the remaining technical issues in defining the Common Lisp
Standard and to resolve technical questions relating to adopted portions of the
standard.
However, the benefits arising from such standardization will not be realized
unless DARPA builds the infrastructure needed to nurture and support the
emerging Common Lisp community. The Common Lisp specification must be
correctly maintained and distributed to those who have need of it. A
validation suite is needed to guide developers toward proper implementations
and to ensure that they have correctly done so. A library of public domain
information concerning Common Lisp (validation suites, useful utility and
functional programs, documentation, tests, implementation guides, etc.) must be
maintained and disseminated. Past and future proceedings of the Executive
Committee must be archived and organized for retrieval by date and topic.
Libraries of public domain information concerning Common Lisp (source and
object code, documentation, tests, implementation guides, etc.) must be
maintained and disseminated. Network mailing lists of people and organizations
participating in the electronic forums used to raise issues, submit
suggestions, and arrive at consensus must be maintained. The messages must be
organized and summarized so that new people can join the forum and participate
in the distributed standardization effort. Finally, travel and administrative
support is needed for the convener of the Common Lisp standardization effort.
The Common Lisp community needs a technically competent support organization
to provide these services. Furthermore, this support group must have no stake
in any Common Lisp implementation so that they can perform the necessary work
with complete impartiality. ISI recognizes the need for these services and has
the technical and administrative expertise to support the Common Lisp
community. Moreover, ISI has the trust of that community. ISI is uniquely
qualified to support this effort because of its personnel, long history of
service support of the Lisp community, and demonstrated ability to manage and
operate service efforts. Bob Mathis was chosen as the convener by the Common
Lisp community. Ron Ohlander was chosen to be a member of the Common Lisp
Executive Board. Richard Berman has formed working relationships with the
validation experts in the vendor organizations. All of these people are ISI
employees. ISI has established good relations with many of these vendors
through its negotiation, purchase, and distribution of Lisp machines for
DARPA's Strategic Computing program. Prior to that, ISI produced, at DARPA's
request, a full compatible Interlisp for the Vax to promote its widespread use.
Several hundred copies have been distributed and the system has been
transferred to DEC for further distribution and maintenance. ISI has
successfully operated and managed the MOSIS service, a TOPS-20 resource center,
and remote support for DARPA's computing services. This combination of
required capabilities makes ISI uniquely qualified for this task.
2. Tasks
2.1. Common Lisp Validation
A public domain validation suite is desperately needed. Several purported
implementations of Common Lisp exist or will exist within the next few months.
The community has no way of determining the degree of compliance obtained by
such implementations. A few companies have extensive (though hardly
comprehensive) validation suites, but all these are proprietary. Building a
public domain validation suite would be quite expensive, would require
expertise in many different areas, and would take any one organization quite a
while to produce (because of staffing and phasing issues).
ISI proposes to pursue a very different approach. At the just concluded Common
Lisp Meeting, we chaired a discussion of the problems concerned with creating
such a public domain validation suite and investigated the alternative of
creating a public domain validation suite from vendor contributions. We found
much support for this alternative among the vendors if the resulting validation
suite would be public domain and if it was collected and maintained by a
technically competent, neutral, and non-commercial organization such as ISI.
This support was quite widespread and included both the vendors with existing
extensive proprietary validation suites and those who had not yet created such
proprietary suites. The former agreed to contribute their existing suite, and
the latter agreed to produce and contribute one for some portion of the Common
Lisp Standard. While these "agreements" are merely expressions of intent at
this point, we feel that they are based on a true sense of the needs of the
emerging Common Lisp community and the benefits that can accrue to the members
of that community. We have been working with these vendors to solidify these
"agreements" into hard commitments and have just begun to receive contributions
from these vendors. For information purposes, we have attached the list of
vendors that have informally agreed to contribute to a public domain Common
Lisp Validation Suite (see Attachment A).
ISI's role would differ for the two types of contributions. For the existing
suites, ISI must:
1. Homogenize the tests so that they are included in a common way and
report their results in a common way (currently, each vendor has
their own conventions).
2. Eliminate duplicate tests.
3. Determine the areas of coverage and the degree of coverage within
those areas.
For the newly produced suites, ISI must:
1. Specify the way that tests will be invoked and report their results.
2. Coordinate the focus of the vendors to maximize coverage.
In addition, ISI must:
1. Build a Validation Manager to invoke and collect results of
individual tests.
2. Determine the validity of each contributed test.
a. Correct any incorrect ones,
b. Forward questionable ones to the Common Lisp Technical
Committee for resolution of ambiguity.
3. Catalog each contributed test, identify its contributor(s), and
place it in an appropriate area of the validation suite.
4. Build and maintain a Public Domain Validation Suite library and
provide access to it.
Finally, ISI must conduct the validation of vendor's implementation. This will
be done by ISI personnel visiting the vendor site. The vendor will provide
visiting validation team access to the software to be validated and the
hardware upon which it runs. The ISI validation team will merely run the
validation suite, collect its results, and submit them to the Common Lisp
Steering Committee. The Committee will evaluate the results and determine the
degree to which the vendor's implementation complies with the Common Lisp
Standard.
2.2. Library of Public Domain Common Lisp Information
ISI will collect and organize public domain Common Lisp information
(currently over 20MB), maintain it in a library, update it as new information
is generated or becomes available, and provide a dissemination mechanism for
it.
We will make use of the ISI, DARPA funded, Common Lisp Framework (CLF)
persistent object oriented data base to store, house, locate and retrieve the
information types below, to link it with other information and to provide
release and version management. A network interface to the CLF data base will
be constructed to permit online retrieval of the archived information. In
addition, CLF's active object base mechanisms will be used to construct an
automated dissemination facility (triggered by new versions of the stored
objects), and an automated postmaster which responds to stylized requests for
information that arrive via electronic mail.
The Network Services group in the Intelligent Systems Division of ISI will be
tasked to accomplish much of the library and document maintenance services.
This group currently exists and is chartered to provide expeditious, useful and
reliable administrative computer and computer network support and service to a
number of clients of the Institute as well as to funded ISI researchers and
support staff. This group has historically been able to bring to the community
a core staff of competent maintenance personnel who will be able to coordinate
and provide the expertise required to help act as a clearing house and a
communications link for the various library activities.
The specific information and procedures, which will be dealt with by a
combination of Network Services and research staff overseeing this portion of
the overall effort, will include the following:
1. Lists of Common Lisp users and implementers: It will be necessary to
keep current lists of all Common Lisp user sites and implementers in
order to ensure proper delivery of appropriate documents. ISI will
undertake this task, distributing the lists to parties that require
them.
2. The Common Lisp specification: The specification will constitute the
baseline document which at all times determines the Common Lisp
language. This baseline document will require strict configuration
management to determine that it is kept appropriately up to date,
while at the same time preserving the integrity of the language.
Proposed changes to this document will me developed, evaluated, and
approved by the Common Lisp Technical Committee. All approved
changes will made by ISI staff. To support this change process, ISI
will collect and coordinate all requests for changes. Such requests
will be consolidated and forwarded to the Technical Committee for
their consideration. ISI will collect information concerning the
actions of the Technical Committee and report results back to
interested implementers and users. Successful use of the
specification may require other explanatory documents for successful
implementation. ISI will develop and distribute such documents, as
well as the specification itself. In addition, ISI will answer
calls and queries concerning technical issues regarding
interpretation and implementation of the Common Lisp specification.
3. The validation tests collected under the previous task: When the
validation tests have been completed, they will be collected and
maintained in a coordinated and accessible database for later
perusal, modification, extension, and dissemination. There are a
number of different mechanisms available which will be applicable
for this chore including: shared Electronic Bulletin Boards,
extensive and moderated mailing lists to the community, and
non-electronic newsletters. The validation test suite will be made
available to whoever requests it so that they can evaluate
implementations of Common Lisp. Instructions for use for use of the
validation test suite will be maintained and provided to interested
parties. Liaison hotlines will be manned to answer queries and to
troubleshoot problems in proper application.
4. An on-line version of the Common Lisp Manual: Maintaining an updated
and current version of the Common Lisp Manual will best be
accomplished by the Documentation Specialist in the Network Services
group under the guidance of a language expert and the Technical
Committee. This document will be periodically changed to correct
errors, extend or refine explanation, and to reflect changes to the
Common Lisp specification. In addition, ISI will maintain a service
to answer phone calls and written queries requesting interpretation
of the manual and to document requests for needed changes. Change
requests will be consolidated and prospective changes that respond
to legitimate requests will be drafted for consideration by the
Technical Committee. Approved changes will be implemented and
revised manuals will be sent to the Common Lisp community.
5. Public domain implementations of Common Lisp or "Yellow Pages"
additions to it: ISI will collect all implementations of Common Lisp
compilers, interpreters, environments, and auxiliary programs
offered by the community for use by other interested sites.
Furthermore, ISI will publish a catalogue of these programs on a
shared Electronic Bulletin Board. Programs will be available
through electronic file transfer from ISI or will be shipped to
interested parties. ISI will put parties who have implementation or
utilization questions into contact with developers of the original
software.
6. Contributed implementation guidelines and hints: Implementation
guidelines and helpful hints contributed by the user community will
be maintained at ISI through a database and historical record of
previous Common Lisp implementations. These archives will help
vendors/contributors to easily access the information they need to
get themselves on the right track for producing their own properly
validated version of Common Lisp. An automated dissemination
facility and automated postmaster will take care of the bulk of the
queries and problems. Liaison hotline services and inhouse research
staff available will resolve the exceptions.
7. Electronic forums on Common Lisp issues: One of ISI's strong suits
is the maintenance and moderating of electronic forums on a variety
of issues. A Common Lisp bulletin board and/or a master mailing
list of principals and players will be effectively managed from ISI.
8. Proceedings of the Common Lisp Executive Committee: Minutes of
Common Lisp Executive Committee meetings will be collected,
archived, transcribed, and selectively published by ISI. This will
be accomplished through the established databases and tools of CLF
as outlined above.
Since there will be a variety of requirements for distribution of requests for
information, for test validation suites, and for other information, ISI is an
ideal site to center this general distribution activity. Hopefully, most of
the distributions will occur electronically via the Internet, DDN and various
other Networks. When this is not possible due to the electronic isolation of
some vendor or site, ISI will be able to transmit information in nearly any
format required including: Magnetic Tape (nearly any format or density), floppy
disk and paper/hardcopy. ISI has a large mix of computers and peripherals as
well as a qualified and experienced Operations and Systems staff which will
allow for this variety of media production (as required). Additionally, with
an Operations staff available 24 hours-a-day, 7 days-a- week, researchers can
be assured maximum availability to the machine resources they might require or
expect to find.
2.3. Travel and Administrative Support for Convener
Bob Mathis, an ISI employee, was chosen as the convener of the Common Lisp
Standardization effort by the community. In this role, he will need substantial
administrative support and will be required to travel extensively, both
domestically and internationally, to attend the various standardization
meetings being held and to coordinate this standardization effort with
appropriate technical organizations. We estimate that 50 to 80 days of his
time and extensive travel, especially internationally, will be required each
year.
3. Current Activity and Plans
3.1. Validation Suites
ISI has established communication with the various Common Lisp vendors
regarding their previously "agreed upon" contributions to the public domain
validation suite and set in motion the process of collecting the existing
validation suites. Most of the vendors are now in the process of sanitizing
some or all of their existing validation suites to remove proprietary and/or
non-portable material prior to delivering the source code to ISI. Only a small
fraction of the expected contributions have actually been received.
As the source code trickles (and then, hopefully, pours) in, it will be
necessary to "re-sanitize" them into some common form. Nearly all of the
vendors are using some form of test management software developed along with
their tests. As one could expect, the nature of this test management is quite
different from vendor to vendor. Many are using some form of proprietary error
control mechanism, an area as yet not standardized in Common Lisp.
From the technical (rather than administrative) point of view, a number of
tasks must occur in order to successfully achieve the desired result of a truly
portable "universal" test suite for Common Lisp. The primary task is one of
understanding. Anyone who has ever had to maintain or extend source code
created by another knows the inherent communication problem in reaching a full
understanding of the source code. In this particular case, we have added the
complexity of trying to understand source code which has not only been written
by a number of others, but is written in and with the purpose of testing an
evolving language. As anyone in the Common Lisp development community could
attest, there are questions as to the exact meaning of a number of areas in the
current language specification (such as it is).
Thus the task becomes one of heavy liaison between not only the ISI technical
personnel responsible for the creation and maintenance of the validation suite
and the vendors, but also between the validation personnel and the technical
steering committee and the general implementors and development community. It
would not be at all surprising if, due to questions raised during the building
of the validation suite, there arose (and subsequently were resolved) a number
of language design and implementation issues.
Once each individual test (of which there may be hundreds or thousands per
vendor contribution) has been understood and validated as to being a test of
actual language features, and also of being a valid test of those features, it
must be incorporated into some kind of framework under which all of the
validation testing occurs. A few vendors have offered to contribute their own
validation managers, but as of this time these have not been received for
evaluation.
The most probable form of organization for the test suite is by sections
numbered as in Steele's book, Common Lisp, the Language. Thus, an individual
test must be exactly "locatable" as to the section in the book which discusses
and explains the feature being tested. Because this book has been much
clarified and revised by discussion over the network, and, in fact, because
this process is ongoing, there is required the development of some "meshing"
between the validation effort and the continuing specification effort.
Naturally, for any such validation suite to be effective it must be both
broad in terms of language issues covered, and deep in the extent of exercising
the full range of functionality of each language feature. The ideal validation
would exhaustively attempt every type of operation with every type of operand,
both legal and intentionally illegal. It is just as important to test that
error conditions are detected and reported correctly as it is to test for
simply correct functionality of legal expressions.
One of the initial hurdles that must be overcome in the creation of a
validation test management program is the nature of the detection and reporting
of exception or error conditions. The common consensus is to use "the error
handling mechanism" of the language. Indeed, all of the vendors who have
offered to contribute test management software, use the language error handling
features. Unfortunately at present there is no standard for the exact
definition and handling of exception conditions, and so each vendor has
implemented their own form of error handling. Either a portable
non-exception-based test control mechanism must be devised, or the error
handling features must be put in place in the language specification so that it
can be relied upon during validation.
During this initial phase of soliciting code contributions from vendors'
existing validation suites, ISI will also be evaluating those contributions
against the idealized validation suite described above. As more vendors
specify the exact nature of their test contributions, ISI can use this survey
to identify the holes in the composite suite formed from the contributions.
Several vendors have indicated that they would be willing to create wholly new
validation tests for specific areas of the Common Lisp Manual. We will
coordinate these vendor activities to maximize coverage and eliminate
duplication. Once a validation framework is decided upon for the individual
tests, we can then specify the format for all these new tests so that the
effort of integrating them into the full validation suite is minimal.
Besides these mostly technical tasks, there is a large administrative
responsibility in the ongoing communication with validation contributors, the
technical committees, the language developers and the Common Lisp user
communities. Not all developers have network access in a form that makes
distribution over the network possible. In the interest of full support for
all vendors and developers, the public domain validation suite should be made
available on tape and in other ways that would facilitate its distribution.
When revisions and/or additions are made to the validation suite, the
interested parties must be notified. Undoubtably, when a validation suite is
made public domain, there will not be complete agreement as to the validity of
the test itself. This could be despite approval by the various committees
involved. Especially in its initial incarnations there will certainly be a
succession of incremental revisions designed to correct flaws in the individual
tests of the validation suite.
To maintain complete impartiality, and to provide for a uniform standard of
reporting, when a vendor desires an official validation rating ISI will conduct
the test of the implementation. By going to the vendor's site we avoid the
need to send hardware to ISI, and all the subsequent problems that revolve
around that. A validation team would actually use the validation suite to
verify the implementation's correctness. The results of this official
validation run would be collected by the validation team, put into a formal
report in a standard format, and forwarded to the Technical Committee for
evaluation. By using this more formal approach, it will be possible for the
Technical Committee to objectively compare different implementations for
determining the level of compliance with the full Common Lisp standard.
3.2. Keeping Track of Decision Making and the "Why's"
Another area of ISI's participation as an administrative body for the Common
Lisp community is technical record keeping. Currently, a great deal of
discussion occurs on the network regarding specific details of the language,
its specification and implementation. Often an apparent consensus is reached
to alter or drop "old" language features, or to add entirely new ones. Yet
there does not appear to be any official statement from a technical steering
committee regarding any decisions to accept proposals. And too, often there is
no formal proposal, but simply a semblance of agreement amongst those arguing a
point.
It is not unusual to see something like:
- As I recall, we discussed point "x" several months ago, but I can't
seem to recall what we decided...
Clearly, this causes repetition of whole discussions, and in general throws
rocks in what is already an unpaved road. Ideally there should be some method
of classifying both the content and nature of each message, as well as some
form of discussion tracing, all built into a kind of archiving methodology
which provides querying and possibly browsing facilities. Once such a
record-keeping system is in place, further discussion participants can be
advised as to the classification system so that they can indicate the
classification for their messages. In the meantime, and especially while
developing the classification method, each message will have to be classified
at ISI.
During these discussions, many valid points are raised and, often, resolved.
A great deal of the philosophy of the language design is contained in these
messages. There are a number of ways in which these messages can be classified
and organized. There are two main areas of classification:
1. The "type" of message.
2. The topic(s) of the message.
While it would be better if a message contained exactly one topic, in
practice even one "topic" easily branches off into several related subjects
which wouldn't be appropriate to separate messages. Thus each message would be
classified by a list of topics discussed. Often this would be a specific
Common Lisp function or feature. At other times it might discuss a more
general area, such as error handling, or string representation. It may be
feasible to assume that there is a finite set of topics into which the more
specific topics can fit. For example, "string representation" might fit under
"strings", as would discussions about specific string functions.
When classifying by topic (and especially when considering a finite set of
topics) there is a useful guide -- Steele's book, Common Lisp, the Language.
The list of finite topics could well be the section numbers in that book, so
that when discussing a particular topic or topics, the message sender must know
what sections of the book contains the material which he has some discussion
concerning. This has the added advantage of making the message sender more
aware of the published information regarding his interest. Thus, if this were
the decided-upon classification method, each message on the network concerning
Common Lisp would have a list of section numbers, put into the message by the
sender.
The querying or browsing facility mentioned above would then allow the user
to view (and summarize, count, etc.) the messages regarding a certain topic.
Naturally these messages would appear in temporal sequence. A typical request
might be to summarize (i.e. print the sender, date and discussion topic) of
each message on a given set of topics within a certain time period. This would
help to locate a specific message by jogging the searchers memory.
The other main form of classification is by "type" of messages. A key type
might be "Ratified Decision", or some similar type. This would be a message
(from the steering committee) officially announcing some change to the language
specification. Like any other message, it would be classified by topic(s). By
using a type-classification as well, a user could now search for "decisions
made about strings between February and June of 1986". If one only cared for
specification changes, this would be an efficient means of getting the concise
information needed.
Other types can be suggested, such as "Start of new discussion", which would
indicate the first message in a new chain of discussion. Or "Clarification
request", "Proposal", etc. Undoubtably the process of building this
record-keeping mechanism will bring to light the required set of message types.
Another valuable means of organizing these messages is by discussion tracing.
By this is meant the linking, in temporal sequence, of each message in a given
discussion, from the inception of the discussion through to its resolution. In
a browsing mode, the user might be able to start from any message and trace the
discussion chain forward and backward to get the full set of things considered
when resolving the discussion. This is especially useful because a great deal
of traffic is currently generated in repeating discussions resolved earlier.
Probably other ways of organizing the Common Lisp discussions will present
themselves as the task progresses. By using the Common Lisp Framework
developed at ISI, each message can be treated as a unique object, and given
properties (such as type and topics) which relate the messages one to another.
The facilities provided under CLF allow for complex searching to be done
amongst these objects. A stylized querying language and a reporting method can
be created so that network users can access the CLF Common Lisp data base to do
the research they need to more optimally interact with the development
community.
4. Milestones
- 3 Months
* Build a Validation Manager to invoke and collect results of
individual tests.
* Coordinate the focus of vendors contributing to Validation Suite
to maximize coverage.
- 6 Months
* Integrate initial contributed Validation Suites into Library
1. Homogenize the tests so that they are included in a common
way and report their results in a common way (currently,
each vendor has their own conventions).
2. Eliminate duplicate tests.
3. Determine the areas of coverage and the degree of coverage
within those areas.
- 9 Months
* For each test in the initial contributed Validation Suites:
1. Determine validity of test
- Revise or remove incorrect tests
- Forward questionable ones to Technical Committee
2. Place test in appropriate portion of Validation Suite
3. Catalog it by its contributor, the test it performs, and
its time of contribution
- 12 Months
* Make information in the Common Lisp Library accessible. This
information includes:
1. The Common Lisp specification.
2. The Public Domain Validation Suite.
3. An on-line version of the Common Lisp Manual.
4. Public Domain Implementations of Common Lisp or "Yellow
Pages" additions to it.
5. Contributed implementation guidelines and hints.
6. Electronic forums on Common Lisp issues.
7. The Proceedings of the Common Lisp Executive Committee.
- 15 Months
* Design procedures by which on-site validation of vendor
implementation of Common Lisp will be carried out. Coordinate
with vendors and Common Lisp community.
- 18 Months
* Automated Postmaster and Dissemination mechanism for Common Lisp
information
* Begin conducting on-site validation of vendor implementations
5. Computing Resources
ISI does not require any additional (DARPA purchased) Common Lisp
Workstations for this project. The necessary workstations will be supplied
from a pool of grant Common Lisp Workstations given to ISI by Hewlett Packard
and Texas Instruments in recognition of DARPA sponsored work in the Software
Sciences Division on FSD.
Operations and maintenance costs of these workstations, however, must be
included in the budget for this effort.
-------
∂05-Jul-86 0823 griss%hplmlg@hplabs.HP.COM Manuals and standards hassles
Received: from HPLABS.HP.COM by SU-AI.ARPA with TCP; 5 Jul 86 08:23:01 PDT
Received: from hplmlg by hplabs.HP.COM ; Sat, 5 Jul 86 08:21:23 pdt
Received: by hplmlg ; Sat, 5 Jul 86 08:21:31 pdt
From: Martin Griss <griss%hplmlg@hplabs.HP.COM>
Message-Id: <8607051521.AA11732@hplmlg>
Date: Saturday, July 5, 1986 08:21:27
Subject: Manuals and standards hassles
To: cl-steering@su-ai.ARPA
Cc: GRISS%hplmlg@hplabs.HP.COM
X-Sent-By-Nmail-Version: 04-Nov-84 17:14:46
Looks like we are heading for yet another manual copyright
hassle. I agree with Scott that waiting for legal hassles around the
Lucid manual and/or the DEC rights to Steele book are probably not
worth the time.
Maybe there is way for Dick Gabriel, and Guy Steele likewise, to
"donate" a significant portion (but not all) of the sources to perhaps
an older version of the manual and book to either CMU or DOD allowing
free adaptation. It may be possible to then freely adapt and combine
these pieces more quickly than starting totally from scratch, yet not
infringe on any copyright (or am I too naive...). This appears to have
some similarity to the mechanism whereby the various validation suites
(or portions thereof) are being combined into a greater "standard"
work at ISI.
Maybe Mathis and Ohlander can help devise a scheme whereby
copyright to the new work does not have to reside with Scott alone,
ultimately to perhap cause him problems similar to those faced by
Steele with DEC. Surely there is a DARPA mechanism to manage
copyright, yet still assure Scott of the him of the recognition (say
as editor of "Final Report of a deliberation of Common LISP standards
subcommitee") that he deserves and CMU will respect.
I also agree with Mathis that Scott should ignore the
ANSI/ISO/Eulisp political problem, and focus his energies and talents
on the technical material. I have talked to Padget, an old friend from
REDUCE and PSL days, and will send a more detailed report on our
meeting later. I have encouraged him to focus on the technical issues,
and experiment with the layered/subset definition approach to more
rigorously defining CL-86, or perhaps have contribution to a later CL,
since we know how long it will take them, and us too...
-------
∂06-Jul-86 1512 FAHLMAN@C.CS.CMU.EDU Manuals and standards hassles
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 6 Jul 86 15:12:24 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 6 Jul 86 18:12:22-EDT
Date: Sun, 6 Jul 1986 18:12 EDT
Message-ID: <FAHLMAN.12220609384.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Martin Griss <griss%hplmlg@HPLABS.HP.COM>
Cc: cl-steering@SU-AI.ARPA
Subject: Manuals and standards hassles
In-reply-to: Msg of 5 Jul 1986 08:21-EDT from Martin Griss <griss%hplmlg at hplabs.HP.COM>
Martin,
Your suggestion that Gabriel and Steele release specific portions of
their manuals is an interesting one, but we won't know what we want to
get rights to until we get down to writing. I don't think they can
release "almost all" without getting into lawyer hassles again.
I've come to the conclusion that doing a new manual from scratch is the
only way to make progress without wasting any further time on legal
hassles, and I've decided that I will find the time to do this. If I
can't just start from one of the existing manuals, it's easier to start
from scratch than to cobble together a lot of little pieces with various
strings attached to each. Then we'll all know exactly what the legal
status of the new work is, and we'll be free to dispose of the rights
however we like.
(Well, that's almost true. It is inevitable that there will some
passages of the new work that sound like the corresponding passages from
Steele or Lucid. That won't be intentional, but sometimes there's an
obvious best way of saying something precisely, and I don't want to go
through too many gyrations to avoid saying things the way the earlier
works did. I'm hoping that Steele and Gabriel can use their influence
to persuade Digital Press's lawyers and Lucid's lawyers, respectively,
that not in anyone's interest to search for little coincidences to
hassle people over. Big coincidences (whole paragraphs, etc.) would be
a different matter, but there won't be any of those.)
As soon as anyone comes up with a way we can all hold the copyright
jointly, or some other plan that makes everyone more comfortable, I will
take whatever steps are necessary to implement that. In the meantime,
I'll continue to hold the copyright, but will not entangle it in any way
without explicit instructions from the combined steering and technical
committees. I don't think that having DOD or CMU or ANSI hold the
copyright would be any better -- I'm less likely to go insane and do
things that would harm Common Lisp than any of those organziations (I
hope!) -- but if the rest of you prefer something like that, I'll
comply.
-- Scott
∂23-Jul-86 1339 FAHLMAN@C.CS.CMU.EDU Japanese liaison
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 23 Jul 86 13:38:44 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 23 Jul 86 16:39:04-EDT
Date: Wed, 23 Jul 1986 16:38 EDT
Message-ID: <FAHLMAN.12225048843.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-steering@SU-AI.ARPA
Subject: Japanese liaison
Regarding M. Ida's mail that there is now an official JIS working group
on Lisp:
I think we now should invite invite the chairman of this group (who
happens to be Ida) to become a member of our steering committee, and to
appoint a voting member to our technical committee for purposes of
formal liaison. It might be best to do this before they all leave for
the Lisp conference (or we can wait and discuss it with them there, but
in that case we should know exactly what we intend to offer them in the
way of formal representation). I really think it would be good to have
them participating formally before we have done a lot of voting. Then
they'll feel like this is partly their Lisp and not just the U.S.
proposal.
I know that we were close to doing this before, when some red flags went
up. But now that there's a JIS committee, we have a more appropriate group
to deal with than the rather ad hoc JEIDA group.
-- Scott
∂25-Jul-86 0730 MATHIS@ADA20.ISI.EDU Re: Japanese liaison
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 25 Jul 86 07:30:10 PDT
Date: 25 Jul 1986 07:29-PDT
Sender: MATHIS@ADA20.ISI.EDU
Subject: Re: Japanese liaison
From: MATHIS@ADA20.ISI.EDU
To: Fahlman@C.CS.CMU.EDU
Cc: cl-steering@SU-AI.ARPA
Message-ID: <[ADA20.ISI.EDU]25-Jul-86 07:29:27.MATHIS>
In-Reply-To: <FAHLMAN.12225048843.BABYL@C.CS.CMU.EDU>
I agree completely with Scott on this point. I seem to recall
from some previous discussion on this point that the rest of you
wanted Scott and I to go ahead when the time was right. Unless
there is some serious objection, I would like Scott to send a
message (speaking for all of us) inviting them along the lines he
suggested and do it this weekend. -- Bob
∂25-Jul-86 0911 FAHLMAN@C.CS.CMU.EDU Japanese liaison
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 25 Jul 86 09:05:48 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 25 Jul 86 11:54:19-EDT
Date: Fri, 25 Jul 1986 11:54 EDT
Message-ID: <FAHLMAN.12225521288.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: MATHIS@ADA20.ISI.EDU
Cc: cl-steering@SU-AI.ARPA
Subject: Japanese liaison
In-reply-to: Msg of 25 Jul 1986 10:29-EDT from MATHIS at ADA20.ISI.EDU
Well, as much as I would like to move quickly on this, it has been made
clear to me that at least some of the technical committee people are not
keeping up with their mail reading, so I can't send a message speaking
for the whole group after giving them only a day or two to object.
Looking at the calendar, I think our best hope is to give people a week
to agree to this, and if they do agree we can raise this issue with Ida
when we meet with him in person in Boston. We must understand what we
want to do by then.
-- Scott
∂25-Jul-86 1518 gls@Think.COM Japanese liaison
Received: from GODOT.THINK.COM by SAIL.STANFORD.EDU with TCP; 25 Jul 86 14:51:37 PDT
Received: from ignatius by Godot.Think.COM via CHAOS; Fri, 25 Jul 86 17:51:40 edt
Date: Fri, 25 Jul 86 17:52 EDT
From: Guy Steele <gls@Think.COM>
Subject: Japanese liaison
To: Fahlman@C.CS.CMU.EDU, MATHIS@ADA20.ISI.EDU
Cc: cl-steering@SU-AI.ARPA, gls@AQUINAS
In-Reply-To: <FAHLMAN.12225521288.BABYL@C.CS.CMU.EDU>
Message-Id: <860725175221.6.GLS@IGNATIUS.THINK.COM>
Date: Fri, 25 Jul 1986 11:54 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Well, as much as I would like to move quickly on this, it has been made
clear to me that at least some of the technical committee people are not
keeping up with their mail reading, so I can't send a message speaking
for the whole group after giving them only a day or two to object.
Looking at the calendar, I think our best hope is to give people a week
to agree to this, and if they do agree we can raise this issue with Ida
when we meet with him in person in Boston. We must understand what we
want to do by then.
-- Scott
I say go for it. By the way, RPG is out of town right now (or perhaps I
should say "in town", since he's in Boston).
--Guy
∂25-Jul-86 1746 FAHLMAN@C.CS.CMU.EDU Japanese liaison
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 25 Jul 86 17:46:11 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 25 Jul 86 20:46:26-EDT
Date: Fri, 25 Jul 1986 20:46 EDT
Message-ID: <FAHLMAN.12225618171.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Guy Steele <gls@ZARATHUSTRA.THINK.COM>
Cc: cl-steering@SU-AI.ARPA
Subject: Japanese liaison
In-reply-to: Msg of 25 Jul 1986 17:52-EDT from Guy Steele <gls at Think.COM>
Well, Gabriel is the one I especially wanted to hear from on this issue,
since he raised the red flag last time. Once we've invited Ida, it's
irrevocable -- not like mere technical committee decisions -- so I want
to be sure there is no dissent on this. (Of course, we could invite
additional Japanese if there are other important factions.) If you
happen to see RPG, maybe you could sound him out on this and let me know
what he thinks.
-- Scott
∂26-Jul-86 1417 FAHLMAN@C.CS.CMU.EDU Back in the Saddle
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 26 Jul 86 14:16:59 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 26 Jul 86 17:17:01-EDT
Date: Sat, 26 Jul 1986 17:16 EDT
Message-ID: <FAHLMAN.12225842192.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Dick Gabriel <RPG@SU-AI.ARPA>
Cc: cl-steering@SU-AI.ARPA
Subject: Back in the Saddle
In-reply-to: Msg of 26 Jul 1986 16:18-EDT from Dick Gabriel <RPG at SU-AI.ARPA>
RPG sent this to CL-TECHNICAL, when it is really a steering matter, I
think.
I'm back from my trip and saw the notes regarding JIS. If
JIS is the proper Japanese standards organization and if
this working group is properly qualified by JIS, then I
believe we should go ahead and invite Ida (finally). Perhaps
Bob Mathis knows the exact nature of JIS and can quickly
bring us up to date.
I will dig up the note from IDA describing the role of JIS and forward
the relvant portions. I believe that this is sort of a combination of
X3 and ACM in Japan.
Ida will be at the Lisp conference, and we can chat with him
then, assuming his english permits.
I believe that the note inviting Ida should neither precede nor
be preceded by a note to a European representative.
It is important that everyone on our committee subscribes in general to
its goals: to fix up the existing Common Lisp spec and to propose the
result as a international standard for Common Lisp. We don't need a
loyalty oath, but that should be the understanding. The Japanese will
have no problem with this. I'd be happy to offer committee membership
to Chailloux and/or one of Padgett and Fitch, but only if they share our
goals in this area. I don't think they do. We should sound them out on
this in Boston, which will make the offer more or less concurrent with
the offer to Ida.
-- Scott
∂26-Jul-86 1452 FAHLMAN@C.CS.CMU.EDU [a37078%ccut.u-tokyo.junet%utokyo-relay.csnet: Lisp standardization]
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 26 Jul 86 14:52:42 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 26 Jul 86 17:53:03-EDT
Date: Sat, 26 Jul 1986 17:53 EDT
Message-ID: <FAHLMAN.12225848755.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-steering@SU-AI.ARPA
Subject: [a37078%ccut.u-tokyo.junet%utokyo-relay.csnet: Lisp standardization]
I forwarded this message from Ida to all of you some time ago, but here
are the excerpts that relate to JIS, just to save you all from having to
look this up again. From what he says, it seems clear that JIS is in
fact the legitimate counterpart to ANSI, and the Japanese organization
that interfaces to ISO. Also that the appropriate heavies, Nakata and
Yoneda, have selected Ida as their designated Lisp guy.
-- Scott
---------------------------------------------------------------------------
...
2)General steps toward the standardization of computer languages in japan.
There is only one committee for MITI whose name is JIS programming language
standardization or so. All the computer languages are defined by this
committee. But the actual working is not carried by the committee, like
SC22 forms WG for each language. The membership of this top committee
are not opened and I am not the member of this top committee.
I think almost all the members are very senior persons.
From my experinece and my knowledge, the standardization is initially
directed by MITI. This task force is undertaken by Jeida or IPSJ.
After the actual works by Jeida or IPSJ finish, MITI calls the members for
the top JIS committee and ask them to guarantee it. The draft which appear to
the top committee is not actually discused, when the language spec is parallely
defined to ANSI.
Jeida standardization team is carried by Prof. Yoneda (u-tokyo).
IPSJ standardization team is carried by prof. Nakata (u-Tsukuba).
Prof. Nakata is an official member of ISO TC22 as a representative of Japan.
(he gave me a copy of Bob Mathis's proposal of Ad Hoc Group on the preparation
of NWI on Prolog and LISP to ISO/TC97/SC22)
The documents appeared at ISO are send to MITI, then forwarded to several
persons, including Prof. Nakata at least.
He has, currently, a role to catch up the standardization of Fortran, Cobol,...
On the other hand, Prof. Yoneda has a role to establish a standard
for more "fresh" languages, like C, Ada, Lisp,...
MITI select and decide which team is more suitable for any computer languages.
Last tuesday, June 10, I was called by the staff of Prof. Yoneda's committee
at Jeida.
He told me that MITI suggest to start the working committee for Lisp
standardization, and that the committee is under Prof. Yoneda's committee
and I should be the chair of the JIS committee also.
Then I will start the working committee to make a JIS draft with 13 members.
the number of members is prior assigned and given to me.
The scheduled dates of this year is one-a-two-month.
The first meeting will be in July.
Prof.Yoneda (and Prof. Nakata) is very senior person.
I think the formal process in Japan is going just like you mentioned.
I mean I agree your suggestion of your mail. i.e. ANY offical activities for
standardization in Japan need senior persons who have responsibilities to
totally control the whole process, even though he has only a basic knowledge
about the language, and he can not understand the details
or he have no time to spare to learn the language details.
...
I think it is very usual to form a JIS working committee which is parallel to
ANSI/ISO committee and the JIS committee will communicate with ANSI committee.
∂26-Jul-86 1935 FAHLMAN@C.CS.CMU.EDU The Lisp Conference handout
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 26 Jul 86 19:35:19 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 26 Jul 86 22:35:37-EDT
Date: Sat, 26 Jul 1986 22:35 EDT
Message-ID: <FAHLMAN.12225900192.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-steering@SU-AI.ARPA
Subject: The Lisp Conference handout
The following is the proposed text for the Lisp conference handout --
one of the ways in which we will officially notify the community about
X3J13 and related matters. The plan is to send this to the Common-Lisp
mailing list before people leave for the conference, and to ask these
people not to bother picking up a hardcopy. Then we'll deliver a couple
of hundred as fliers to sit on the registration table or somewhere. Any
problems with the following message? (I'm still trying to squeeze it
down to one side of one page.)
-- Scott
---------------------------------------------------------------------------
Status of Common Lisp Standardization Efforts
Common Lisp is fast becoming a de facto standard for Lisp, especially in
the commercial world where the need for a standard, widely accepted Lisp
dialect has long been felt. Almost all Lisp suppliers in the U.S. now
offer, or intend to offer, implementations of Common Lisp. The language
is now available on most of the workstations and mainframes that are
used by the AI research community. Several Japanese companies have also
been active in Common Lisp development, and a Japanese standardization
committee has been established. Common Lisp is being used in Europe,
and the European efforts at Lisp standardization are taking Common Lisp
as one important input.
At a meeting in Boston in December, 1985, representatives from the
Common Lisp community agreed to form technical and steering committees
to work on Common Lisp standardization. The technical committee is to
develop a detailed language specification for Common Lisp; the steering
committee is to work on the non-technical aspects of the standardization
process. A group of people, including five key contributors to the
original Common Lisp design, was chosen to select the members for these
new committees; that task was completed in March of 1986.
The technical committee members are Alan Bawden, Daniel Boborow, Richard
Gabriel, Martin Griss, David Moon, Jonathan Rees, Guy L. Steele Jr., and
Scott Fahlman (chairman). The steering committee members are Richard
Gabriel, John McCarthy, Ronald Ohlander, Stephen Squires, Guy L. Steele
Jr., and Robert Mathis (chairman). It is expected that some non-U.S.
members will be added to both committees in the near future. Both of
these committees are interim bodies that will be integrated into the
normal standards process, once that process is operating fully.
A formal proposal was made to X3, the accredited U.S. standards
committee for information processing systems, to establish a technical
committee for Common Lisp standardization. This proposal was accepted;
the Common Lisp committee is called X3J13. Plans are also being made
for the establishment of an international committee for Lisp
standardization under ISO. The formation of an X3 technical committee
is the normal way for the U.S. to participate in ISO activities.
Most of the technical discussion on Common Lisp occurs on the ARPAnet
via the mailing list "common-lisp@@sail.stanford.edu", administered by
Richard P. Gabriel (rpg@@sail.stanford.edu). A number of other networks
have mail gateways to the ARPAnet, making it possible for almost all
interested parties to participate in the technical discussions.
Electronic mail communication has been established with particpants in
Japan and Europe.
The first meeting of X3J13, the U.S. Technical Committee for the
standardization of Lisp, will be Tuesday and Wednesday, September 23 and
24, 1986, in Washington, DC, at the headquarters of CBEMA, Suite 500,
311 First St, NW. On Tuesday (23) the meeting will be from 10am to 5pm;
on Wednesday (24) the meeting will be from 9am to 3pm. No special hotel
arrangements are being made.
Membership in X3 technical committees is open to all who actively
participate (attend meetings or correspond) and pay an annual service
fee (about $175). US citizenship or residency is not required. The
first meeting is important since policies and procedures for X3
technical committees will be discussed and specific plans for the Lisp
activity will be made.
Anyone interested in joining X3J13, and particularly anyone planning to
attend the first meeting, should contact the convenor for X3J13: Dr.
Robert Mathis, 9712 Ceralene Dr., Fairfax, VA 22032. Phone: (703)
425-5923. Arpanet: mathis@@b.isi.edu.
∂28-Jul-86 0746 gls@Think.COM Japanese liaison
Received: from GODOT.THINK.COM by SAIL.STANFORD.EDU with TCP; 28 Jul 86 07:46:18 PDT
Received: from kant by Godot.Think.COM via CHAOS; Mon, 28 Jul 86 10:46:27 edt
Date: Mon, 28 Jul 86 10:47 EDT
From: Guy Steele <gls@Think.COM>
Subject: Japanese liaison
To: Fahlman@C.CS.CMU.EDU, gls@ZARATHUSTRA
Cc: cl-steering@SU-AI.ARPA, gls@AQUINAS
In-Reply-To: <FAHLMAN.12225618171.BABYL@C.CS.CMU.EDU>
Message-Id: <860728104712.1.GLS@KANT.THINK.COM>
Date: Fri, 25 Jul 1986 20:46 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Well, Gabriel is the one I especially wanted to hear from on this issue,
since he raised the red flag last time. Once we've invited Ida, it's
irrevocable -- not like mere technical committee decisions -- so I want
to be sure there is no dissent on this. (Of course, we could invite
additional Japanese if there are other important factions.) If you
happen to see RPG, maybe you could sound him out on this and let me know
what he thinks.
-- Scott
Good. I just realized that the juxtaposition of two sentences in my
last note ("go for it" and "RPG is away") might be misconstrued as
urging you to go ahead without waiting for RPG. Fortunately, you took
the advice as intended: I say "go for it", but note that RPG is away
(and therefore you may wish to wait in order to get his input). I'll
try to be more careful from now on.
RPG will be back home by today, I think.
--Guy
∂28-Jul-86 0851 gls@Think.COM The Lisp Conference handout
Received: from GODOT.THINK.COM by SAIL.STANFORD.EDU with TCP; 28 Jul 86 08:51:19 PDT
Received: from kant by Godot.Think.COM via CHAOS; Mon, 28 Jul 86 11:51:36 edt
Date: Mon, 28 Jul 86 11:52 EDT
From: Guy Steele <gls@Think.COM>
Subject: The Lisp Conference handout
To: Fahlman@C.CS.CMU.EDU, cl-steering@SU-AI.ARPA
Cc: gls@AQUINAS
In-Reply-To: <FAHLMAN.12225900192.BABYL@C.CS.CMU.EDU>
Message-Id: <860728115224.6.GLS@KANT.THINK.COM>
Looks pretty good. I like it. Minor bugs: Bobrow's name is misspelled,
as is the word "participant". The names are not consistent: "Richard
Gabriel" in one place and "Richard P. Gabriel" in another. Unless you
choose to introduce initials into other names, such as "David A. Moon"
or "Scott E. Fahlman", you may as well shorten my name to just "Guy
Steele" in the two places it appears.
This document seems to address primarily those interested in being
involved in the U.S. effort. It might be appropriate to contact Ida and
the Eulisp folks so that they can either supply a paragraph apiece for
this handout or provide handouts of their own specifying how to get
involved with those efforts.
--Guy
∂28-Jul-86 1149 OHLANDER@B.ISI.EDU Re: Japanese liaison
Received: from B.ISI.EDU by SAIL.STANFORD.EDU with TCP; 28 Jul 86 11:48:02 PDT
Date: 28 Jul 1986 11:45-PDT
Sender: OHLANDER@B.ISI.EDU
Subject: Re: Japanese liaison
From: OHLANDER@B.ISI.EDU
To: Fahlman@C.CS.CMU.EDU
Cc: cl-steering@SU-AI.ARPA
Message-ID: <[B.ISI.EDU]28-Jul-86 11:45:57.OHLANDER>
In-Reply-To: <FAHLMAN.12225048843.BABYL@C.CS.CMU.EDU>
Scott,
I agree with Bob Mathis on getting closure on this thing.
I assume that Ida has the proper stature with his Japanese colleagues
to successfully represent other interests in Japan.
Ron
∂29-Jul-86 0642 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM Japanese liaison
Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 29 Jul 86 06:41:47 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 51545; Mon 28-Jul-86 16:37:30 EDT
Date: Mon, 28 Jul 86 16:37 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Japanese liaison
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>
cc: MATHIS@ADA20.ISI.EDU, cl-steering@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12225521288.BABYL@C.CS.CMU.EDU>
Message-ID: <860728163725.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Fri, 25 Jul 1986 11:54 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Well, as much as I would like to move quickly on this, it has been made
clear to me that at least some of the technical committee people are not
keeping up with their mail reading, so I can't send a message speaking
for the whole group after giving them only a day or two to object.
Note that this is a steering committee matter, not a technical committee matter.
But perhaps your use of the word technical was just a typo, since you did
send the message to the correct mailing list.
If I wanted to have an opinion on this subject, I would be on the steering
committee.
∂09-Aug-86 2056 FAHLMAN@C.CS.CMU.EDU Issues
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 9 Aug 86 20:55:55 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 9 Aug 86 23:56:11-EDT
Date: Sat, 9 Aug 1986 23:56 EDT
Message-ID: <FAHLMAN.12229584869.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-steering@SU-AI.ARPA
Subject: Issues
We've got (at least) three "where do we go from here" issues to think
about:
First, and most important, there's the whole issue of what we're going
to do about standards and about resolving the technical questions that
are before us. As I understand it, the resolution of the EuLisp affair
was more or less that (a) neither we nor the EuLisp people will try to
rush through an official standard in the next couple of years, (b) we
will try to develop some sort of informal standard as a way of cleaning
up the short-term problems with Common Lisp, and (c) we will work with
the EuLisp people (and the Japanese) to develop a formal ISO standard in
the far distant future. For this future standard, we will agree to
consider somewhat deeper changes than we have been considering for the
short-term Common Lisp cleanup; on the other hand, it must be made clear
to the EuLisp group that they don't get to dictate whatever changes they
want, unless they want the resulting "standard" to be opposed and, if
adopted, ignored.
The above is my second-hand understanding of the outcome of the
discussions AFTER the mass meeting on standardization, between Steele,
Gabriel, and Mathis on our side and the key Eulisp people, so it may not
be quite right. As I understand it, some thought is being given to
using a second edition of CLtL as the focus for the short-term, informal
fixup of Common Lisp. If we do this, we need to work out some mechanism
for making the little decisions (do we go with something like the
current technical committee?) and we need to make sure that Guy is not
exposed to nasty liability issues if he changes the book without some
sort of formal standards process to hide behind.
The second big issue is committee membership (assuming we still have
something like a technical committee). Given the confusion during the
Lisp conference, I don't know whether any formal invitations were issued
to the Japanese or to the Europeans. I guess we need to figure out what
the structure is before issuing any inviations.
During the Conference Fritz Kunze of Franz Inc. took me aside and made
clear the following: they want one of their people (John Foderaro) on
the technical committee, they believe that they are being harmed in the
marketplace (relaive to Lucid) by not having someone on the committee,
and they "intend to change this situation, whatever it takes". I assume
this means a big fight at X3 and, if that fails, a lawsuit. Of course,
if these committees went away altogether, so would the problem, but if
we proceed as an informal "gang of eight" working on CLtL2, we'd better
understand what our legal position is, because Kunze will make it as hot
for us as he can.
I made clear my own view of this the last time this issue came up (when
we were selecting the current committees): I think we should add
Foderaro to the committee and avoid a fight over this. I don't think
that Foderaro has demonstrated any particular talent for language
design, but his implementation experience would make his inclusion
defensible, at least. He has a consitutency, of sorts, outside of his
own company: there are still a lot of Franz users out there. I don't
believe that Franz Inc. is really being harmed by not having someone on
the technical committee, but I believe that Kunze sincerely believes
this -- it's easier for him to blame his marketing problems on an
external conspiracy than on any problems with his own company. In
principle, if we take Foderaro, there are a lot of other companies that
could demand a place as well, but as far as I know Franz Inc is the only
company that is seriously disgruntled by the current setup. If we add
Foderaro, no real harm is done; if we don't, there will be a nasty fight
that we don't really need right now, and we'll have to be very careful
at every turn not to expose ourselves to a lawsuit. If the rest of you
want to fight it out on this issue, fine, but I personally am not
well-covered against this kind of trouble and will probably try to get
myself out of the line of fire.
Finally, there is the issue of leadership in the technical
decision-making. As I told most of you at the conference, I am
resigning as chairman of the technical committee. For the last couple
of weeks I have been reconsidering my own priorities. I've put a lot of
years into Common Lisp, and for the past few years I've been the person
who has taken responsibility for moving things forward: whatever had to
be done, if nobody else could be found, I made it my problem. My
feeling was that Common Lisp should not be allowed to unravel, whatever
the cost. This has taken a lot of time and has been very stressful at
times. I have decided that I no longer want to do this, and that I
couldn't do it for much longer even if I wanted to -- the accumulated
strain is taking its toll. I am willing to coninue as an active member
of the technical committee, but not in a leadership role. I hope that
someone else can be found to assume this responsibility, or that the
leadership role can be split up and redefined so that it is less
stressful, but I'm determined to stay out of this in any event. If no
one can be found to push things forward in the future, then Common Lisp
may stop improving; I'd hate to see that, but I could live with it.
I would like to announce my resignation soon. It would look better if a
new (perhaps interim) chairman were announced at the same time. If
necessary, I could delay the resignation until the Washington meeting in
September, but I won't be pushing on any technical issues or moderating
the mailing list discussion in the meantime.
-- Scott
∂11-Aug-86 0725 MATHIS@ADA20.ISI.EDU Re: Issues
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 11 Aug 86 07:25:20 PDT
Date: 11 Aug 1986 07:25-PDT
Sender: MATHIS@ADA20.ISI.EDU
Subject: Re: Issues
From: MATHIS@ADA20.ISI.EDU
To: Fahlman@C.CS.CMU.EDU
Cc: cl-steering@SU-AI.ARPA
Message-ID: <[ADA20.ISI.EDU]11-Aug-86 07:25:00.MATHIS>
In-Reply-To: <FAHLMAN.12229584869.BABYL@C.CS.CMU.EDU>
I think Scott had a reasonably good summary of what we are trying
to do re ISO. We didn't mean to leave anybody out at our after
the meeting meeting. What basically happened was that Chailloux,
Gabriel, and Steele seemed to agree on the possible discussion of
some technical issue so I asked Padget to write down a possible
statement for an ISO new work item. Everybody wanted to agree on
something and this was bland enough to get some agreement.
Basically we agreed that the ISO standard would have levels,
there was no discussion of how much any group would have to
compromise.
From the ISO new work item proposal:
Title: Development of an ISO standard for Lisp.
Purpose: The standard will specify the syntax, semantics, and
conformity requirements of the language in terms of a few
coherent levels of increasing magnitude and breadth. The work
will draw on the experiences of the Lisp communities in the U.S.,
Europe, and Japan.
Program of Work: The first meeting of an ISO Working Group on
Lisp could be during the Summer or early Fall of 1987.
Considerable work on Lisp and its possible standard specification
is already underway. This will be drawn together in the ISO
Working Group. A Draft Proposal should be ready by July 1989 for
SC balloting.
I think the best work for the US in X3J13 is the clarification of
the current Steele specification. The X3J13 Committee could do
their work as primarily a list of issues and decisions about
those issues. If Steele wants to produce a second edition
incorporating those changes, he could do so. I do not think it
appropriate to move toward any more formal standardization than
that at the ANSI level. This would prepare the US to take a very
strong role in the ISO work.
About committees -- Separate from our Steering and Technical
committees, I asked Chailloux, Padget, Ida, and Gabriel to join
me as a kind of international coordinating committee with
unspecified roles and responsibilities. I did this to give them
a feeling of being included and also to separate it from our US
activities. I think our current technical and steering
committees were always seen as temporary and their end is coming.
For the technical committee, I am very sad that Scott has had to
make the decision he has. We talked about it at some length. I
hope he can maintain an active role.
The September meeting of X3J13 would be an ideal place to elect a
new chairman and membership for the technical committee. We
should take the composition of that committee as a priority
discussion item. Then Scott could pick a time to announce his
resignation and we could announce that the selection of members
and chairman of the technical committee would be an item on the
agenda of the X3J13 meeting.
-- Bob
∂16-Aug-86 1152 RPG Various Issues (cont'd)
To: cl-steering@SAIL.STANFORD.EDU
Scott's resignation is a blow to the technical committee. I believe that
the duties Scott performed can be broken down as follows:
Titular Head: anyone who can speak calmly
Technical Lead: distributed among the technical committee
On the issue of EuLisp/Common Lisp, I think that there is a hope
of accomplishing the merger rather than using it as a delaying tactic.
The technical compromise from our point of view is merging the
value/function name spaces. This puts user code in jeopardy, and it
exposes a problem with macros. We are experiencing some of the macro
problems already, and we should look closely at a solution.
As part my vague position on the ``kind of international coordinating
committee with unspecified roles and responsibilities,'' I plan to attend
about 1 out of 3 EuLisp meetings (assuming I can find some way to pay for
the trips). The face-to-face EuLisp/Common Lisp meeting tuesday night at
the Lisp conference demonstrated some hard feelings on both sides. The
private continuation of that discussion over beer was much calmer and
demonstrates the power of personal interaction rather than long-distance
carping.
I heard it suggested (by Sussman among others) that Common Lisp has `won' and
EuLisp is simply a desperation move on the part of the European community.
That might be true, but I think it doesn't serve the internation Lisp community
well to pursue that strategy, especially if we can clean up Common Lisp
in the balance.
On the Kunze issue, as you know I am a major naysayer to including
Foderaro on the Technical committee. We have discussed his qualifcations
at length, and I don't want to repeat either them or our conclusions.
I spoke with Kunze myself, and he stated that Franz lost a major account
because someone said that they did not believe that Franz could follow
Common Lisp developments and that Franz could not speak for the Common Lisp
community. I believe that membership by any single person or every person
in Franz on X3J13 should solve that particular problem without having to
place someone on the Technical committee, which I see as more select.
I question Franz's ability to play an effective role on the select committees
based on a press conference held by Franz at AAAI. The press conference touched
on the recent events surrounding EuLisp. No one from Franz was at the tuesday
night meeting, but at the press conference the relationship between EuLisp
and Common Lisp was explained to the press. Franz stated that Common Lisp
had won and that the best strategy was for the US to ignore the Europeans.
A British reporter was at the press conference and was upset by the attitude
taken by Franz. She came and talked to me about the relationship between
EuLisp and Common Lisp, at which point I told her of the ISO new work item that
Bob Mathis quoted to this list.
Perhaps the best bet is to let X3J13 vote on the members of the Technical
and Steering committees, but for the time being, if the current Technical
committee votes to help Franz's marketting department, I will go along with
the decision.
-rpg-
∂16-Aug-86 1403 DLW@ELEPHANT-BUTTE.SCRC.Symbolics.COM Various Issues (cont'd)
Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 16 Aug 86 14:02:52 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 63593; Sat 16-Aug-86 16:45:50 EDT
Date: Sat, 16 Aug 86 16:50 EDT
From: Daniel L. Weinreb <DLW@QUABBIN.SCRC.Symbolics.COM>
Subject: Various Issues (cont'd)
To: RPG@SAIL.STANFORD.EDU, cl-steering@SAIL.STANFORD.EDU
In-Reply-To: The message of 16 Aug 86 14:52 EDT from Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Message-ID: <860816165009.3.DLW@CHICOPEE.SCRC.Symbolics.COM>
I'd like to point out one specific problem with putting Fodorero onto
the technical committee: how will it look to the marketing departments
of the other vendors, who do not have "representatives" [sic] on the
technical committee? If you add Fodorero, you'll have to explain why.
Even if you come up with a bland explanation, it's still pretty likely
that word will get out that it was done because Franz claimed that they
were at a marketing disadvantage, etc., etc. At this point, you will be
in the position of having confirmed that, indeed, Franz was at a
disadvantage, and now they are not. Our position, that members of the
technical committee are individuals rather than company representatives,
will be untenable. If you were in the marketing group at TI, what would
you think at this point? Or LMI or Gold Hill or Integrated Inference
Machines or the KCl company? When they approach you with the same
request, what will you say? I think this issue deserves consideration.
∂16-Aug-86 2039 FAHLMAN@C.CS.CMU.EDU Various Issues (cont'd)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 16 Aug 86 20:39:28 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 16 Aug 86 23:39:56-EDT
Date: Sat, 16 Aug 1986 23:39 EDT
Message-ID: <FAHLMAN.12231416922.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Dick Gabriel <RPG@SU-AI.ARPA>
Cc: cl-steering@SU-AI.ARPA
Subject: Various Issues (cont'd)
In-reply-to: Msg of 16 Aug 1986 14:52-EDT from Dick Gabriel <RPG at SAIL.STANFORD.EDU>
Perhaps the best bet is to let X3J13 vote on the members of the Technical
and Steering committees, but for the time being, if the current Technical
committee votes to help Franz's marketting department, I will go along with
the decision.
Probably the Franz people will be willing to wait until the X3J13
meeting and see what develops there, before they do anything drastic.
I suggested to Kunze that he do this, and he seemed to agree at the
time.
If the Franz people come out of Washington feeling screwed, it must be
very clear that everything was done by the book, and even then it could
get messy. Maybe there's some way they end up with the official
participation they seem to want, without establishing the principle that
whoever makes the most threats gets to call the tune.
I'm not sure what to expect at the Washington meeting. Presumably
anyone present who says he wants to participate gets to be on the X3J13
committee? And it is then this big committee that selects something
like technical and steering committees? What sorts of rules will govern
this? Can one company pack the meeting? Do we even want to propose
that the current technical and steering committees, more or less, be
adopted by X3J13? I assume that this arpanet style of discussion is
foreign to X3 and that most efforts in the past have progressed via face
to face meetings, with some very small group doing all the preparation
behind the scenes.
I'd be interested in hearing what Bob Mathis thinks is going to go on in
Washington, since he is the only one of us (I think) who has been
through this before.
-- Scott
∂17-Aug-86 1024 RPG Varia Concerning September Meeting
To: cl-steering@SAIL.STANFORD.EDU
I presume that no voting can happen at the meeting in September.
It is not practical for all interested parties to show up, and
it certainly has not been advertised. If Bob Mathis says I'm wrong,
that you can bet that 55 people from Lucid will be there, plus proxies from
all our clients.
That last sentence ought to convince anyone who thinks that we should
have a hard vote that it is a bad idea, because a strategy like the one
I just outlined will occur to other people as well.
I think we ought to propose that the current ad hoc committees be continued,
and I presume Kunze will propose additional members. At that point DEC and
some of the others will see what's happening and probably propose some of their
own, or else they'll stand up and state that the current committees are
OK. Were I cynical, I could propose we start to lobby with the various
companies to block such a move to expand.
In fact, I think we ought to propose that the current technical committee
write a new specification and let X3J13, as a whole, judge it.
Another possible scenario for the September meeting is to simply report on
progress, vote on procedures, take opinions on the EuLisp question, take
opinions on the depth of changes allowed, and approach the meeting as if
it were presumed that the current technical committee will remain in
place until the first draft is ready.
As far as the planning is concerned, I understand it to be the case that
Bob Mathis is `at our service,' rather than the other way around. At the
EuLisp meeting he stated that the current Common Lisp constituency could
not back down from standarization now that the ball is rolling (China might
step in was a proposed scenario), but I think that underestimates the
strength of the community that would be backing down.
-rpg-
∂17-Aug-86 1126 MATHIS@ADA20.ISI.EDU X3J13 and issues
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 17 Aug 86 11:26:17 PDT
Date: 17 Aug 1986 11:26-PDT
Sender: MATHIS@ADA20.ISI.EDU
Subject: X3J13 and issues
From: MATHIS@ADA20.ISI.EDU
To: cl-steering@SU-AI.ARPA
Cc: Mathis@ADA20.ISI.EDU
Message-ID: <[ADA20.ISI.EDU]17-Aug-86 11:26:09.MATHIS>
Let's not talk about digging in heels or backing down. The J
committees are "technical" committees from the X3 standpoint.
The openness of X3J13 means that interested people can be on the
"technical" committee. What we need is a subcommittee that gets
the work done -- call it a "clean-up" committee (nobody ever
wants to be on those).
Before the September meeting it would be good to have a strategy
for who should be on that committee. I would like it to have a
chairman who could divide up the work. I would also not like
there to be any open controversy about it membership. The people
we want on it should be at the September meeting. It should not
be a list of names but rather a group of workers. We also need
it to have a strategy of more frequent meetings.
Bob
∂18-Aug-86 0822 FAHLMAN@C.CS.CMU.EDU X3J13 and issues
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 18 Aug 86 08:21:52 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 18 Aug 86 11:21:42-EDT
Date: Mon, 18 Aug 1986 11:21 EDT
Message-ID: <FAHLMAN.12231806814.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: MATHIS@ADA20.ISI.EDU
Cc: cl-steering@SU-AI.ARPA
Subject: X3J13 and issues
In-reply-to: Msg of 17 Aug 1986 14:26-EDT from MATHIS at ADA20.ISI.EDU
So perhaps the model we want to promote is that X3J13 is the "technical
committee". This is open to anyone who puts in the time and money, and
it is the body with actual authority to make technical decisions. The
Franz people will be on there, and that will give them the kind of
official representation they seem to crave.
Since that group will be too large to get any complicated work done,
there will have to be subcommittees that produce well-debugged proposals
on various issues. Certainly there would be a subcommittee on
object-oriented programming, one on errors (which might converge very
quickly), and something we might call "cleanup" dealing with all the
little problems of the current manual. Maybe also one on characters
(they would try to work with the Japanese to develop a character
standard that accommodates Kanji and maybe flushes fonts and/or bits),
and one on standards issues relating to the compiler -- there is a
complicated nest of issues in here that want to be worked on together.
I guess that there would still be need for some sort of steering
committee as well, though maybe this is just a set of informal advisors
to Mathis.
The current technical committe people would be on various of these
subcommittees. An advantage of this setup is that some additional
people from the heavily involved companies could get into the act, where
before we tried hard to avoid dupllication. KMP should be involved in
the error subcommittee, Gregor in objects, and so on. The only
politically sensitive one might be "cleanup", which deals with most of
the things the old technical committee was trying to deal with earlier.
But since the real power rests with the full X3J13, which is open, maybe
people will relax a little.
There's still the issue of whether certain companies try to pack X3J13
with their own people. Do things move slowly enough that we could
safely wait to see if anyone else tries this, rather than launching a
first strike? Or is there some procedural mechanism in X3 that makes
packing impossible or ineffective? I guess there's always the practical
threat that if some splinter group takes over X3J13, the companies that
don't like this can agree to ignore this committee and all its works.
(If this threat exists in credible form, there is little chance of ever
having the situation arise.)
-- Scott
∂18-Aug-86 1149 OHLANDER@B.ISI.EDU Franz Issue
Received: from B.ISI.EDU by SAIL.STANFORD.EDU with TCP; 18 Aug 86 11:48:59 PDT
Date: 18 Aug 1986 11:47-PDT
Sender: OHLANDER@B.ISI.EDU
Subject: Franz Issue
From: OHLANDER@B.ISI.EDU
To: cl-steering@SU-AI.ARPA
Message-ID: <[B.ISI.EDU]18-Aug-86 11:47:39.OHLANDER>
I have very strong objections to being blackmailed to place someone from Franz
on the Technical Committee. I also don't understand why Franz, among all of
the other developers of LISP, has to have special help in this area. While it
is true that some vendors have members on the committee, there are sound
historical reasons for such participation. I feel that, if we allow Kunze to
exert this kind of pressure, we have to be prepared to submit to anyone who
has the same kind of problem. At the same time, I want to be practical. I
think Gabriel's recommendation to put someone from Franz on the X3J13 group
may solve the problem.
In regard to Common Lisp and Eulisp, I have to believe that Common Lisp's
position is very solid and the time will be on our side. If the community at
large can benefit from some accomodation of Eulisp issues, then we should make
an honest attempt to achieve some sort of integration and cleanup. While this
is progressing, I think we will see even more solid instantiation of CL with
embracement by the the Japanese. I believe this will influence the Europeans
to make concessions in our favor.
Ron
∂18-Aug-86 1211 gls@Think.COM X3J13 and issues
Received: from GODOT.THINK.COM by SAIL.STANFORD.EDU with TCP; 18 Aug 86 12:11:17 PDT
Received: from faustinus by Godot.Think.COM via CHAOS; Mon, 18 Aug 86 15:11:16 edt
Date: Mon, 18 Aug 86 15:12 EDT
From: Guy Steele <gls@Think.COM>
Subject: X3J13 and issues
To: Fahlman@C.CS.CMU.EDU
Cc: cl-steering@SU-AI.ARPA, gls@AQUINAS
In-Reply-To: <FAHLMAN.12231806814.BABYL@C.CS.CMU.EDU>
Message-Id: <860818151209.5.GLS@FAUSTINUS.THINK.COM>
When we first set up the current technical committee, the officially
announced theory was that its purpose was to tide the world over until
X3J13 happened, and perhaps also get a substantial amount of the cleanup
work done. (We have not done the technical cleanup work, of course, but
it appears that we have done a great deal of political cleanup work.)
X3 does have procedures to prevent packing of committees; you can bet
that this problem was addressed long ago. Here is my inductive
understanding of the rules, based on observing X3J3 minutes and X3J11
meetings. In general anyone can attend and participate in discussion,
but each company only gets one vote. A company designates an official
representative and an alternate. Persons who are independent of a
company may attend as independent consultants. A person gets a vote
only if he (or his designated alternate) has attended at least two of
the last three meetings. This last rule puts a premium on attending the
first meeting: attendees of the initial meeting get votes right away,
but people who first attend at the second meeting don't get a vote until
the third or fourth meeting. It also requires a certain commitment and
prevents proxy fights: you must actually be there to get a vote.
In practice technical issues are resolved by subcommittees, including
"committee of the whole". Their reports are then referred to the main
committee for final votes. (This is often a rubber stamp, but not
always. In X3J11 we very often spent an entire day in committee of the
whole and voted for some set of features; then we would rise from
committee of the whole and the exact same set of people would vote to
turn down the proposal after all.)
At this stage I would not mess with Foderaro or anyone else. Let's sit
tight and see what happens in Washington. If Franz doesn't care enough
to have anyone at the Eulisp meeting, will they give a fig for X3J13?
It is an obvious opportunity for anyone complaining about the current
setup to put up or shut up.
--Guy
∂18-Aug-86 1210 gls@Think.COM X3J13 and issues
Received: from GODOT.THINK.COM by SAIL.STANFORD.EDU with TCP; 18 Aug 86 12:10:03 PDT
Received: from faustinus by Godot.Think.COM via CHAOS; Mon, 18 Aug 86 15:10:11 edt
Date: Mon, 18 Aug 86 15:11 EDT
From: Guy Steele <gls@Think.COM>
Subject: X3J13 and issues
To: Fahlman@C.CS.CMU.EDU
Cc: cl-steering@SU-AI.ARPA, gls@AQUINAS
In-Reply-To: <FAHLMAN.12231806814.BABYL@C.CS.CMU.EDU>
Message-Id: <860818151103.4.GLS@FAUSTINUS.THINK.COM>
When we first set up the current technical committee, the officially
announced theory was that its purpose was to tide the world over until
X3J13 happened, and perhaps also get a substantial amount of the cleanup
work done. (We have not done the technical cleanup work, of course, but
it appears that we have done a great deal of political cleanup work.)
X3 does have procedures to prevent packing of committees; you can bet
that this problem was addressed long ago. Here is my inductive
understanding of the rules, based on observing X3J3 minutes and X3J11
meetings. In general anyone can attend and participate in discussion,
but each company only gets one vote. A company designates an official
representative and an alternate. Persons who are independent of a
company may attend as independent consultants. A person gets a vote
only if he (or his designated alternate) has attended at least two of
the last three meetings. This last rule puts a premium on attending the
first meeting: attendees of the initial meeting get votes right away,
but people who first attend at the second meeting don't get a vote until
the third or fourth meeting. It also requires a certain commitment and
prevents proxy fights: you must actually be there to get a vote.
In practice technical issues are resolved by subcommittees, including
"committee of the whole". Their reports are then referred to the main
committee for final votes. (This is often a rubber stamp, but not
always. In X3J11 we very often spent an entire day in committee of the
whole and voted for some set of features; then we would rise from
committee of the whole and the exact same set of people would vote to
turn down the proposal after all.)
At this stage I would not mess with Foderaro of anyone else. Let's sit
tight and see what happens in Washington. If Franz doesn't care enough
to have anyone at the Eulisp meeting, will they give a fig for X3J13?
It is an obvious opportunity for anyone complaining about the current
setup to put up or shut up.
--Guy
∂24-Aug-86 2005 OHLANDER@B.ISI.EDU Re: X3J13 and issues
Received: from B.ISI.EDU by SAIL.STANFORD.EDU with TCP; 24 Aug 86 20:05:19 PDT
Date: 24 Aug 1986 20:03-PDT
Sender: OHLANDER@B.ISI.EDU
Subject: Re: X3J13 and issues
From: OHLANDER@B.ISI.EDU
To: Fahlman@C.CS.CMU.EDU
Cc: cl-steering@SU-AI.ARPA
Message-ID: <[B.ISI.EDU]24-Aug-86 20:03:25.OHLANDER>
In-Reply-To: <FAHLMAN.12231806814.BABYL@C.CS.CMU.EDU>
Scott,
I don't like the idea of making the X3J13 committee the "Technical Committee."
There should certainly be an X3J13 committee with participation open to anyone
that wants to participate. However, I also firmly believe there will have to
be a highly competent, small Common LISP Technical Committee that takes care
of the language. I'm afraid that an X3J13 committee would be too unwieldly
and perhaps too politicized to operate effectively in keeping the language up
to date for the real users. These Ansi committees are often good, but it is
my experience that they move slowly. Another problem is that such a committee
may not sit forever and might not feel obliged to hand on the baton. My
recommendation is to go with both the X3J13 committee and the existing
technical committee until we see how things work out.
On a separate issue at least one vendor that things aren't happening quickly
enough in Common Lisp. TI is putting a major investment in their
next release of Common Lisp and would dearly love to know if an
object-oriented system is to be agreed on soon. In addition, they would like
to see a window standard and tell me a number of vendors feel strongly about
getting one. Apparently Intellicorp is willing to put theirs forward as a
standard.
Ron
∂25-Aug-86 0946 RPG Various Issues
To: cl-steering@SAIL.STANFORD.EDU
Having X3J13 be the Technical Committee and the current members
of cl-technical be the Specification Committee seem to accomplish the
two goals of having a hardcore - real - technical committee and of
assuaging the minions who feel screwed at being left out of the
standarization process. However, this argument assumes that it is the
fact of being on the technical committee rather than the substance
of being on that committee that is the sticking point.
On object-oriented programming, things are progressing about as
fast as they can right now: Bobrow and Moon got together to agree
on a compromise in principle right after the Lisp conference. Currently
a PhD-level hacker-writer from Lucid, Gregor Kiczales, and I are meeting
for several hours every day writing the specification for this agreed-upon
standard. I expect that a preliminary draft will be ready by the end
of September. A more nearly well-proofread version should be ready for
`public' comment by the end of October. For the moment, if you think
`CommonLoops' you will be nearly right on target.
On the subject of window system specifications, you'll recall that
IntelliCorp and Lucid were working together on one. Lucid parted company
with IntelliCorp's Common Windows because it specified a user interface
rather than a user-interface-building window system. Lucid built, instead,
a set of tools from which Common Windows can be built. However, as Mike
Grandfield of LMI points out, neither the Lucid window toolset nor the
IntelliCorp specification are adequate to handle the display list
style and the distributed window systems rapidly approaching.
Moreover, Xerox pondered the IntelliCorp spec and criticized it along
the same lines Lucid did.
I think we would err if we adopted the IntelliCorp spec without
susbtantial thought.
-rpg-
∂25-Aug-86 0951 FAHLMAN@C.CS.CMU.EDU X3J13 and issues
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 25 Aug 86 09:49:36 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 25 Aug 86 12:49:28-EDT
Date: Mon, 25 Aug 1986 12:49 EDT
Message-ID: <FAHLMAN.12233657781.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: OHLANDER@B.ISI.EDU
Cc: cl-steering@SU-AI.ARPA
Subject: X3J13 and issues
In-reply-to: Msg of 24 Aug 1986 23:03-EDT from OHLANDER at B.ISI.EDU
Certainly things are not happening quickly enough on the "cleanup"
stuff. Things seem to be moving as fast as possible on the object stuff
-- anyone who wants to track this closely should get intot he loop on
the COmmonLoops activity.
As for windows, I have long felt that thiungs would not move forward
until we had a couple of concrete, detailed proposals on the table, with
implementations for some machine or other. Those can come from
anywhere. People who don't like the pace should get to work, not just
gripe.
-- Scott
∂27-Aug-86 1024 OHLANDER@B.ISI.EDU Re: X3J13 and issues
Received: from B.ISI.EDU by SAIL.STANFORD.EDU with TCP; 27 Aug 86 10:22:58 PDT
Date: 27 Aug 1986 10:20-PDT
Sender: OHLANDER@B.ISI.EDU
Subject: Re: X3J13 and issues
From: OHLANDER@B.ISI.EDU
To: Fahlman@C.CS.CMU.EDU
Cc: cl-steering@SU-AI.ARPA
Message-ID: <[B.ISI.EDU]27-Aug-86 10:20:50.OHLANDER>
In-Reply-To: <FAHLMAN.12233657781.BABYL@C.CS.CMU.EDU>
Scott,
I have heard of two potential standards for windows, one
from Intellicorp and one from DEC. DEC has taken the "X"
Window stuff from MIT (withsome modifications from CMU)
and is pushing it as a standard for, at least, UNIX systems. I
will try to find out more about these efforts and see if I
can get some specifications for review.
Ron
∂27-Aug-86 1054 FAHLMAN@C.CS.CMU.EDU X3J13 and issues
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 27 Aug 86 10:54:07 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 27 Aug 86 13:50:25-EDT
Date: Wed, 27 Aug 1986 13:50 EDT
Message-ID: <FAHLMAN.12234193167.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: OHLANDER@B.ISI.EDU
Cc: cl-steering@SU-AI.ARPA
Subject: X3J13 and issues
In-reply-to: Msg of 27 Aug 1986 13:20-EDT from OHLANDER at B.ISI.EDU
I'd very much like to see a standard Common Lisp interface to X, since
that window system seems to be quite popular in the unix world. I
hadn't heard about DEC's efforts along these lines. We'll have to see
whether this makes sense as a Common Lisp standard (I doubt that it
would), but for people living on X or something similar, it would be
very nice if they all did their window hacking in a compatible way. If
this can be packaged up with public domain code that will implement X on
any vanilla Unix 4.2/4.3 (and Mach), then this would create a useful
standard for that part of the world.
-- Scott
∂02-Sep-86 0402 MATHIS@ADA20.ISI.EDU Ida's thoughts on international standardization
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 2 Sep 86 04:01:49 PDT
Date: 2 Sep 1986 04:00-PDT
Sender: MATHIS@ADA20.ISI.EDU
Subject: Ida's thoughts on international standardization
Subject: [Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet...]
From: MATHIS@ADA20.ISI.EDU
To: cl-steering@SU-AI.ARPA
Message-ID: <[ADA20.ISI.EDU] 2-Sep-86 04:00:57.MATHIS>
Thought you all might like to see this message from Ida,
particularly the later half. -- Bob
Begin forwarded message
Received: FROM RELAY.CS.NET BY USC-ISIF.ARPA WITH TCP ; 29 Aug 86 10:03:43 PDT
from utokyo-relay by csnet-relay.csnet id ab15969; 29 Aug 86 12:27 EDT
by u-tokyo.junet (4.12/4.9J-1[JUNET-CSNET])
id AA00231; Fri, 29 Aug 86 19:51:04+0900
by ccut.u-tokyo.junet (4.12/6.1Junet)
id AA12062; Fri, 29 Aug 86 09:08:00+0900
Date: Fri, 29 Aug 86 09:08:00+0900
From: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA>
To: MATHIS%ADA20.ISI.EDU@UTOKYO-RELAY.CSNET,
a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA
Cc: Mathis@ADA20.ISI.EDU
Subject: Re: ANSI Meeting
Return-Path: <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA>
Message-ID: <8608290008.AA12062@ccut.u-tokyo.junet>
Thank you for your letter.
Should I send $175 or so, which is necessesary to join ANSI ?
Or I can receive documents with free charge ?
I am ready to pay, of cause.
I have a desire to visit USA on December or Feb.'87.
Because, the school season is
for fall semester until 18 Dec.
I have winter semester schedule for Jan.8 to Feb.15.
Spring semester will start at April 5th or so.
So, If I want to spare all the time I have in USA,
Ican be in USA during 20 Dec to Jan7th,
Feb.17 to April 3rd.
In march, I may visit MIT AI-lab for a month for my personal research work, but not yet fixed.
JIS WG 2nd meeting will be held at Sept.5th.
It will determine the schedule forthe comming 3 years.
So, I think it is very important.
I already told them through junet, japan unix net, that,
ANSI will make Common Lisp as the official standard,
which is headed by you.
ANSI will do it , may be, in 1987.
ISO will start in 1987 and want to have a first DP in 1989 summer.
CommonLoops will be added into the Common Lisp spec.
(After the some polish up taking the staffs of newFlavors)
ISO will also be headed by you.
-----
I think Prof. Fahlman have not so interest in international standardization now.
I have got a contact from Jerome Chailloux by uucp unix net.
He want to seek a kind of 'compromise' with Common Lisp.
Because, Europeian computer companies already start to make
Common Lisp implementation,
with the assisit of Lucid, KCL, ...
I and rpg found we have a same opinion that Eulisp will naturally merged into CL or naturally disapper, if ISO will take a enough time to discuss.
In japan, there are several persons and companies, which
do not want to have a Common Lisp implementation.
But, I will discuss with them with my sincere.
JIS schedule will be,
the first year (1986 summer to 1987 summer) will make a basic understanding
that we will make a LISP official standard esspecially on CL.
Some questions or modification requests may arise and I will send them to the
technical committee.
The second year and the third year ( 1987 summer to 1989 summer) will amke
a draft for JIS which should conform to ISO standard.
The schedule I have in my mind will be done is I do not know.
Only God knows !
I pray God and I will do my best.
Best Regards,
Masayuki Ida
ida%utokyo-relay.csnet@csnet-relay.arpa
-----
--------------------
End forwarded message
∂19-Sep-86 1003 gls@Think.COM Digital Press
Received: from GODOT.THINK.COM by SAIL.STANFORD.EDU with TCP; 19 Sep 86 10:03:29 PDT
Received: from yon by Godot.Think.COM via CHAOS; Fri, 19 Sep 86 13:02:44 edt
Date: Fri, 19 Sep 86 13:03 EDT
From: Guy Steele <gls@Think.COM>
Subject: Digital Press
To: cl-technical@SU-AI.ARPA
Cc: cl-steering@SU-AI.ARPA, gls@AQUINAS
Message-Id: <860919130341.2.GLS@YON.THINK.COM>
I met with Mike Meehan and Chase Duffy of Digital Press yesterday.
No shatteringly new topics, but refreshing of old issues:
(1) They are still waiting for a letter from X3J13 requesting
nonexclusive rights to use portions of CLtL as a basis for a standard.
I was under the impression that Bob Mathis was going to write this.
Was I wrong, or are we waiting for the first X3J13 meeting to have
such a letter authorized by the committee? In any case, they are
ready to give permission just as soon as a letter is received.
(2) They would like to put out a second edition of CLtL during the
summer of 1987. (Major constraint: it would be nice to have it out
for AAAI. Minor constraint: it would be nice to have it out before
July 1 because of Digital press fiscal year.)
(a) I think this is an appropriate time to fix a large number of minor
textual and typographical problems. Chase Duffy and I are plotting to
produce a much better index than the last time around, using a
combination of Thinking Machines indexing software and a professional
indexer who is given more than just a weekend to go over it.
(Apparently the most frequent criticism of the book is that the index
is poor. The second most frequent is that the pages fall out of the
perfect binding under heavy use--they're working on that one, too.)
(b) I plan to go over the text systematically looking for a number
of things, and also inserting many more examples. Now that we have
some real Common Lisp code, I would like to extract some examples
from real use. In particular, while I like phlogiston, it would be
nice to have a real-world example of the use of the package and
module primitives. Any suggestions?
(c) I of course am completely unwilling to make substantive changes to
the text without basing it on decisions of the committee. It would be
nice if my list of typographical correction got formal approval at the
first meeting, and if my long list of issues from last December could
be resolved within the next few months (Scott's issues too).
(d) As far as I am concerned such a second edition could contain a
preliminary (i.e., not ANSI-official) description of Common Loops.
This is a double-edged sword. If we are agreed on nearly all of the
content, this is a vehicle for distributing the design fast so that
everyone can implement it. On the other hand, if we are not agreed in
time, then jumping the gun on publication could cause chaos.
(e) Regarding the function-cell/value-cell thing: if there is a
possibility of ever merging them in the future, such a second edition
could provide early warning ("the following language change is under
consideration; here's some advice on writing programs to avoid
problems if the change is made").
(3) They recognize the need and desire to have on-line copies of the
documentation, but currently have no precedent for appropriate
licensing agreements. What is really needed, I think, is for someone
to propose an actual agreement to them now, for real, so that they can
spring their lawyers into action now. (Basically lawyers won't
prepare ahead for a hypothetical case on speculation.)
--Guy